BeebSCSI 7_7

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Tue Sep 25, 2018 7:37 pm

I'm glad you are having some success with the boards :)

There are lots of BeebSCSIs in use, and it acts exactly like a real Winchester. So if you are having issues it's 99.99% sure it isn't the BeebSCSI design - far more likely to be incorrect assembly or a dodgy Beeb/connector. It works fine with the multitude of old and new add-ons I have (and I know others are using it with the nula boards, pi copros and such); there around 100 or so boards in the wild (that I know of), so it's pretty well proven by now.

The connectors were chosen because they are small (people want small boards, so there really isn't much choice) and the JST connectors were the best in terms of polarity protection - I agree they are a bit tricky to make cables for, but the design was for people to build and sell... and sellers don't want ham-fisted users plugging stuff in backwards :)

Having said all of this, the design is open-hardware - if you'd prefer 5 inch car battery terminals, just load it up in KiCAD and change it ;)

User avatar
Elminster
Posts: 3143
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: BeebSCSI 7_7

Post by Elminster » Tue Sep 25, 2018 7:44 pm

simoni wrote:
Tue Sep 25, 2018 7:37 pm
I'm glad you are having some success with the boards :)

There are lots of BeebSCSIs in use, and it acts exactly like a real Winchester. So if you are having issues it's 99.99% sure it isn't the BeebSCSI design - far more likely to be incorrect assembly or a dodgy Beeb/connector. It works fine with the multitude of old and new add-ons I have (and I know others are using it with the nula boards, pi copros and such); there around 100 or so boards in the wild (that I know of), so it's pretty well proven by now.
It will be an incompatiability somewhere I should think. The cable I used I unplugged my beebsid from, and often plug in External DC there as well. But I get odd issue with compatability between the External DC on 1mhz and the internal SPROM ethenet module (Ethernet hangs if external DC plugged in on 1 Mhz bus on that machine, there is a thread on here somewhere about that from years ago). So not really surprised. Hence just going to go try it in a unexpanded master. Works fine on the Beeb B. Will give it ago on Electron AP5 next.
The connectors were chosen because they are small (people want small boards, so there really isn't much choice) and the JST connectors were the best in terms of polarity protection - I agree they are a bit tricky to make cables for, but the design was for people to build and sell... and sellers don't want ham-fisted users plugging stuff in backwards :)

Having said all of this, the design is open-hardware - if you'd prefer 5 inch car battery terminals, just load it up in KiCAD and change it ;)
No issue with connector per sa, just be good if silk screen was easier to read, but now I build the connector I dont care :) I hadnt done 0.65 before but wasnt that hard, just time consuming. Was quite enjoyable, I found the Tant's and USB connector the hardest. Would definetely get a reflow oven if I was doing more than 10 of them.
Last edited by Elminster on Tue Sep 25, 2018 7:47 pm, edited 2 times in total.

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Tue Sep 25, 2018 7:53 pm

If there is an incompatibility I'd put good money on it not being the BeebSCSI - it was very carefully designed to follow Acorn's 1MHz bus application note and uses the Acorn specified page addresses for SCSI; other devices (especially IDE devices) illegally use the reserved SCSI page FC mapping. As for the GoSDC or sprow ethernet modules, well they are both closed-source - so it's anyone's guess what they do, or how well/badly they are implemented. My advice would be - don't buy any modern add-ons for an Acorn unless it's open-source - otherwise a) you don't know if it's implemented correctly and b) you (and others) can't change it if it's not :)

User avatar
Elminster
Posts: 3143
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: BeebSCSI 7_7

Post by Elminster » Tue Sep 25, 2018 8:14 pm

simoni wrote:
Tue Sep 25, 2018 7:53 pm
If there is an incompatibility I'd put good money on it not being the BeebSCSI - it was very carefully designed to follow Acorn's 1MHz bus application note and uses the Acorn specified page addresses for SCSI; other devices (especially IDE devices) illegally use the reserved SCSI page FC mapping. As for the GoSDC or sprow ethernet modules, well they are both closed-source - so it's anyone's guess what they do, or how well/badly they are implemented. My advice would be - don't buy any modern add-ons for an Acorn unless it's open-source - otherwise a) you don't know if it's implemented correctly and b) you (and others) can't change it if it's not :)
Not attributing blame to anything or anyone, compatabilites between software/hardware is a fact of life, just stating my test results. I think you products are great, and if everything worked first time I would never learn anything (I stole that quote).

Okay it works fine on my other rarely used master (forgot that has a SPROW ARM co pro in it, but seems to be okay). So defintely that specific master and its combinations of 'stuff' that is the issue. Will come back to it later. Next stop to test on heavily modified Electron.

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Sat Oct 06, 2018 10:01 pm

I thought I'd put this here, it seems to be the most recent BeebSCSI topic and I couldn't find a general discussion thread.

Just tried my BeebSCSI mini for the first time today.

It doesn't fit under a Master of course, so I had to use a 34-way extension cable. It's a bit unfortunate that the board gets in the way of the lugs on an extension cable, so in the end I had to use one without lugs. I also had to bend the power pins up a bit to get anything to plug into them.

It was interesting - and reassuringly retro - to see that it's necessary to use an ACB4000 type format routine to format a "drive". Most of the other modern-day hard drive solutions will just accept the writing of the first 7 sectors of FS map and root to a blank drive. It seems BeebSCSI requires the mode select and format unit process to be gone through.

By using sectors per track of 32 (instead of the standard 33 in the ACB4000 controller) you can get much rounder total sectors - 32 heads x 32 sectors per track x 2048 cylinders will give you exactly 2,097,152 sectors, ie. 512MB exactly and the maximum ADFS can accept.

The Adaptec controller doesn't allow the user to set the sectors per track, however, which is set by the controller internally depending on the interleave. An interleave of 1 will get you 32 spt, any other figure gets 33. Superform uses an interleave of 5 and it doesn't give the user a choice. So to do this either needs Superform editing manually, or use of some other Adaptec based formatter (eg. my own enhancement of Superform, "Ultraform", which does allow the interleave to be set).

A side effect of this is that BeebSCSI assumes 33 spt when writing the DAT file to the card, so the file is too long. I don't know if there are any problems caused by this yet.
Image

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Sun Oct 07, 2018 4:24 am

It doesn't fit under a Master of course, so I had to use a 34-way extension cable. It's a bit unfortunate that the board gets in the way of the lugs on an extension cable, so in the end I had to use one without lugs. I also had to bend the power pins up a bit to get anything to plug into them.
The BeebSCSI mini board is really designed with the BBC Micro in mind. The 7_7 'official' board will fit inside the Master where the AIV board is supposed to go.
It was interesting - and reassuringly retro - to see that it's necessary to use an ACB4000 type format routine to format a "drive". Most of the other modern-day hard drive solutions will just accept the writing of the first 7 sectors of FS map and root to a blank drive. It seems BeebSCSI requires the mode select and format unit process to be gone through.
BeebSCSI was designed to emulate a proper Winchester drive - the reason why you need to use the SuperForm application is that it uses some specific SCSI commands to explain the geometry of the required drive. BeebSCSI then saves that to SD card (in the same format BeebEm uses in a .dsc file). Then, if the host requests, it can respond correctly with the geometry. Any modern solution that can't do this; is doing it wrong ;)

Of course, disc geometry is meaningless to BeebSCSI - but there are a number of bits of software out there that 'expect' a real SCSI drive - actually SuperForm is one of them; if you attempt to run it on BeebEm, it will hang as the SCSI emulation isn't correct.

If you turn on the SCSI trace output from BeebSCSI (with a serial lead attached) the board will actually explain to you the geometry and how it's interpreting it; if you give it a LUN image file and don't include the .dsc, it will also work it out for itself and add one. BeebSCSI also supports the SCSI translate commands (that go from geometry to addresses) and will respond correctly to the host.

Everything is designed like a SCSI-1 Turing test; it should be impossible to tell the difference between BeebSCSI and a real Winchester from the host.

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Sun Oct 07, 2018 4:11 pm

It does seem to assume that the sectors-per-track is always 33, when creating the DAT file, whereas it might not always be depending on the interleave used in the formatter.

I've found a curious problem whereby the access speed slows to a crawl the further away from sector zero. Unfortunately this makes BeebSCSI unusable at present with the Level 3 Econet server, as the initialiser takes 20 minutes to lay out the disc, and the server takes 8-12 minutes to mount it.

Here are some example screens, using the ADT *SECTORS command and OSWORD &72, 8. I had to insert the TIME$ reading as well because the actual measured time was almost the same in every case, but of course the internal timer halts whilst the 1MHz bus is occupied, so it gives a false reading. As you can see, the initial reads occur at a rate of several per second when looking at TIME$, slowing to only one or two per second as the end of the "disc" is reached.
October2018a110.png
October2018a112.png
October2018a117.png
October2018a118.png
October2018a122.png
October2018a124.png
Is it something to do with the way the FAT system accesses the DAT file? Anybody else having the same problem?
Image

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Sun Oct 07, 2018 6:24 pm

BeebSCSI is open-source - for details of how the sense and translate commands work take a look at this:

https://github.com/simoninns/BeebSCSI/b ... si.c#L1308

The code is commented; so it should be easy to understand.

As for the slow-down - well SD card access times do get slower the further out you get; but it shouldn't be that slow.

a) are you using a modern class 10 or better SD card?
b) was the card freshly formatted when you added the LUNs?
c) do you have loads of SCSI jukebox partitions?

if the answer is no, no, no - then get a good branded SD card, format it and retest.

Otherwise, hook a serial terminal up - turn on SCSI tracing and see what's going on (you will be able to see if the pause is the host, or BeebSCSI waiting for the SD card). I'm assuming you flashed the BeebSCSI binary from the provided .BIN file - if you compiled it yourself; make sure you compiled it as release not debug - the debug configuration has SCSI tracing turned on by default (and this makes the device much slower).

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Mon Oct 08, 2018 11:42 am

It's a new card, 32GB class 10 Kingston mini-SD. I didn't actually format it beforehand, I was recording the process for a future picture set, so I was expecting one of the steps to have been "need to format the card first". After doing a mode select manually I put the card in the PC expecting to format, but already BeebSCSI0 was there with a DSC file of the mode select parameters.

Linux fdisk told me its format was W95 FAT32 so I think that's all right, but I will try another card (I have 3 other identical, so I need to get a different brand).

I haven't done anything with Juke boxes yet, so it's just BeebSCSI0 and 3 or 4 LUN DAT files plus DSC in there.

I don't know what version of firmware came with it, but I decided to upgrade to 2.4 anyway. It now has the LED on constantly, but faint, which it didn't do before.

At first it was considerably worse, waiting 10 seconds part way through my read test and then giving disc error 2C to every subsequent access, and not correcting itself till either the card was reinserted or the board powered off. It seems to have settled down now, but the sluggish read times persist.

I've had a look at the code on the sectors-per-track point, I need to give that some more thought, I don't think there's a quick fix, as the format time interleave parameter isn't immediately available to the host subsequently.
Image

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Mon Oct 08, 2018 11:50 am

At first it was considerably worse, waiting 10 seconds part way through my read test and then giving disc error 2C to every subsequent access, and not correcting itself till either the card was reinserted or the board powered off. It seems to have settled down now, but the sluggish read times persist.
That's not normal - It's highly likely that either your 1MHz bus has a problem, or the BeebSCSI is not correctly constructed. I've had no feedback from any other user about 2C errors or seconds-long access times.

It sounds like the bus is having problems and that makes me think your resistor networks on the BeebSCSI aren't soldered correctly - this would cause interrupt delays and have the type of effect your are seeing; it's worth checking with a multimeter between the input pin and the back of the resistor networks to ensure you really do have pull-up and down termination of all of the pins and/or take a look at the soldering with an microscope.

Edit: the faint LED is deliberate - it lets you see the board is powered. The new firmware has brightness control of the LED, so it can display more information (and looks a lot nicer too)
Last edited by simoni on Mon Oct 08, 2018 11:51 am, edited 1 time in total.

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Mon Oct 08, 2018 11:57 am

Yes, I'd read about the LED light change in the upgrade notes, that's how I knew the new firmware wasn't already installed.

It might be a power thing, I am using the PSU aux output although the arrangement is shall we say a bit Heath Robinson - although the LED is on constantly, so it is working.

I've a second BeebSCSI mini, I'll try the second board next and see if that makes any difference.
Image

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Mon Oct 08, 2018 12:05 pm

Second board does the same, so it's either:

1. Both boards
2. The ribbon cable
3. The card
4. The power cable

Next I think I'd better plug it in straight underneath a BBC B to eliminate the cable being a problem.
Image

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Mon Oct 08, 2018 12:07 pm

or 5) The computer ;)

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Tue Oct 09, 2018 8:09 am

I'm seeing exactly the same problem, in the same way both on a Master and on a Model B. I actually first noticed it trying to initialise the Level 3 File Server software on the Master - it was taking a really long time, but I had to give up after an hour or so and then found this thread!

I've got a BeebSCSI Mini V_7_5_1_Mini connected to the external 1MHz bus of the Master with an extension cable, or directly attached to the Model B's 1MHz bus and powered from the Tube connector. I'm using a Samsung 32 Gbyte class 6 card.

I typed in BeebMaster's benchmarks, and I see the same decreasing performance, so I enabled BeebSCSI debugging with *FX 147, 68, 1 and the results are here, with timestamps added as I captured the traces:

Master: https://gist.github.com/chrisa/a906d5c4 ... 7572c74235
Model B: https://gist.github.com/chrisa/dcf78a55 ... f8776fc164

The Model B logs have high-resolution timestamps, which I forgot to do when capturing from the Master, but I think they're similar enough anyway.

The behaviour is completely consistent - running the benchmark always produces the same "gradual slowdown" behaviour. Using much smaller offsets for the reads gives much more even timings with no obvious slowdown, whether on the large LUN or on a second, much smaller LUN.

I haven't upgraded the firmware on the BeebSCSI, although I don't actually know the version it's currently running -- is there a way to tell?

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Tue Oct 09, 2018 8:24 am

I'm seeing exactly the same problem
"exactly the same" as in long access times or "exactly the same" as in log access times and 2C disc errors?

I can see from the logs you provided (thanks!) that the final read6 command in the log takes 1.26 seconds to seek and retrieve the data from the SD card - which does seem way too long. The total SCSI transaction time is 1.80 seconds.

This means it's probably something to do with the ChanFS FAT library the code is using. I will have to set up a system and see if I can recreate the issue; probably won't be until the weekend though when I have time. In the meantime, if you could upgrade to the latest firmware and retest on a Master (with the time-stamping) that would be really useful (since the Master is my main dev environment). I've never used a L3 FS, so I'll try to find another way to fill up the disc.

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Tue Oct 09, 2018 8:31 am

Ah, sorry! Exactly the same as in long access times only, I am not seeing any 2C disc errors, no errors at all in fact.

I'll upgrade to the latest release firmware when I get a chance. A question on the firmware updates from SD card though: is it possible to recover from a "bad" firmware update via SD card just by attempting to upgrade again the same way with a known-good image? I'd happily try some more debugging if I knew I wasn't going to brick the card.

User avatar
danielj
Posts: 6684
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: BeebSCSI 7_7

Post by danielj » Tue Oct 09, 2018 8:39 am

If worst comes to worst you're welcome to send the beebscsi to me and I'll unbrick it, but I can't imagine you'll manage to destroy the bootloader :D

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Tue Oct 09, 2018 8:40 am

Yes, there is no way the firmware update from the SD card can overwrite the bootloader - so you can happily hop from firmware to firmware. If an update fails, you can just do it again.

The only restriction is that the bootloader doesn't understand exFAT, so the upgrade SD card needs to be FAT. The main firmware understands both FAT and exFAT (required for cards bigger than 32Gb).

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Tue Oct 09, 2018 9:00 am

OK, great, thanks - I'll see what I can do. Hopefully I won't need to take up danielj's kind offer!

User avatar
danielj
Posts: 6684
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: BeebSCSI 7_7

Post by danielj » Tue Oct 09, 2018 9:13 am

I'm quite confident you won't :)

d.

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Tue Oct 09, 2018 9:19 pm

OK, I upgraded to the latest release firmware with no issues, and it reports itself as:

Code: Select all

Oct 09 22:06:12.595016
Oct 09 22:06:12.595238 BeebSCSI - Acorn SCSI-1 Emulation
Oct 09 22:06:12.595339
Oct 09 22:06:12.595425 (c)2018 Simon Inns
Oct 09 22:06:12.595511 https://www.domesday86.com
Oct 09 22:06:12.615803 Open-source GPLv3 firmware
Oct 09 22:06:12.616033
Oct 09 22:06:12.616204 Firmware: V002.004
Oct 09 22:06:12.616808 Emulation mode is Winchester (ADFS SCSI-1 hard-drive)
Oct 09 22:06:12.617291 USB capable board not detected
Oct 09 22:06:12.823423
Running the same benchmark produced the same slowdown on both the Model B and the Master, and the log with high-res timing, taken on the Master, is here:

https://gist.github.com/chrisa/76894d84 ... 44292a6a45

I managed to build the firmware from source with a Makefile, so I should be able to try out running with more debug. I've also got some 8Gbyte Class 10 cards coming tomorrow, so I'll see if those make any difference.

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Tue Oct 09, 2018 9:35 pm

I'm glad it wasn't just me having this problem!

I haven't got round to testing it in a BBC B yet, I couldn't fit it under Station 128 without everything carefully balanced on top wanting to do a runner, and I don't think it will fit anyway unless I get some other connector for the power.
Image

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Wed Oct 10, 2018 11:07 pm

Well, I got the new Class 10 SD cards, and things looked much the same. I didn't do any timing but the slowdown is still obvious.

However, the BeebSCSI_AVR source code is extremely clear, and I was able to dig in and take a look around really easily - nice work!

The thing that jumps out to me, thinking about the slowdown we're seeing, is that each SCSI read operation involves a FAT open/lseek/reads.../close sequence. If it were reasonable to leave the LUN image files open indefinitely, reads and writes could be faster than now, especially if it were also possible (RAM permitting) to use the "fast seek" mode of the FAT library.

I've started having a look at what it takes to go in this direction, and I've not seen anything to suggest it'd be impossible. Maybe I'm missing something you've already run into here?

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Thu Oct 11, 2018 2:59 am

I'm buried in coding on another project at the moment which I need to finish (past of the LaserDisc decoding work for Domesday86) which is why I haven't had time to look into this yet. It's entirely possible that there are some quick optimisation wins by modifying the code. The idea of the open design was that others we welcome to (and encouraged) to dig into the code and make it better.

If you have an AVR programmer you can use the JTAG to do rapid program and test cycles, but the bootloader programmer works too. Feel free to dig in; fresh eyes on it would only be a good thing and, if you come up with something good, send a pull request to the git repo :)

I'm assuming that you've already seen the tech documentation available? There is a guide to the structure of the AVR code in there too. Have a play! :)

User avatar
simoni
Posts: 442
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: BeebSCSI 7_7

Post by simoni » Thu Nov 29, 2018 8:39 am

I been trying (and failing) to recreate this issue. I filled a 32Gb card with 20Gbs of SCSI juke directories, with each LUN at 512Mb. In every LUN I put 460Mbs of data and then ran speed tests reading and writing to the LUNs. As expected it gets a little slower, but measured in microseconds not seconds.

Is there any way I can get an image of the SD card you're using and some detailed reproduction steps? You're welcome to PM me with a link to files.

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Sat Dec 08, 2018 11:50 am

I'll try to get some detailed steps sorted out, but the slowdown I've been seeing using BeebMaster's BASIC benchmark appears to be related to the sector offset within one SCSI LUN, not the offset of the LUN data file within the FAT filesystem on the SD card.

It should be possible to reproduce this problem with just the one LUN from the "Quick Start" SD image on domesday86.com (which is what I've been using), plus the BASIC listing given by BeebMaster a while back. I have that typed in, so I'll put a .ssd with it somewhere.

User avatar
BeebMaster
Posts: 2632
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: BeebSCSI 7_7

Post by BeebMaster » Sat Dec 08, 2018 1:44 pm

Yes, it didn't seem to matter where the data file is on the SD card, but rather what part of the data file was being accessed, with the problem being that the further away from "ADFS Sector 0", the slower the access time.

It became particularly noticeable with the Level 3 Econet because the initaliser and then the file server all access the entirety of the "disc". The free space bitmap is written at fixed intervals all the way from start to finish of the disc, by the initialiser, and then read by the file server software when starting up.
Image

chrisa
Posts: 9
Joined: Sat Jan 21, 2017 7:02 pm
Contact:

Re: BeebSCSI 7_7

Post by chrisa » Sat Dec 08, 2018 3:01 pm

OK, so here's an SSD with a BASIC program "OSWREAD" which is what I've been using to demonstrate this issue:

https://github.com/chrisa/BeebSCSI/raw/ ... swread.ssd

It should be enough to just put the QuickStart SD image on a card, then load up that SSD and run the program - I'm running on a Master, so TIME$ shows the wall time.

Post Reply