Memory issues with multiple Microdrives?

[dfzx]

Over on tlienhard.com there's a discussion in German about my IF1/Microdrive device.

https://forum.tlienhard.com/phpBB3/view ... hp?p=60117

Google translate tells me that someone is asking, amongst other stuff, this question:

"In the original, each Microdrive requires a RAM buffer of something like 256 bytes inserted between the system variables and the basic start. So there was always the problem with the Spectrum that programs with a low RamTop suffered from a lack of memory and were cut off with the original Interface 1... such a Clear 24500 was sometimes squeezed out to the last byte.

"Does this storage problem still apply?

"Does that apply all the more for 8 installed drives? I usually had 2 drives on it, but with 4-5 drives the usable basic memory shifted up by a good kilobyte, 16K games like Jetpac or Cookie could no longer be loaded unless you loaded them into the higher memory and moved them then back down. Does that still apply?"

I'm aware of the extra memory memory requirements of the microdrive channels, but that bit at the end about 16K games is new to me. Are there compatibility issues that I don't know about?

A re-read of the IF1 ROM code suggests that the microdrive channel memory is only claimed when the microdrive is accessed, so it looks to me like there would only be an issue if you did CAT 1, CAT 2, CAT 3, and then tried to load a 16K game. But I'm not sure, there might be a loop in there which claims memory for channels for all attached Microdrives. Does anyone know?

[mjwilson]

Just guessing but maybe they're talking about loading those games from Microdrive?

[dfzx]

Just guessing but maybe they're talking about loading those games from Microdrive?

Yes, I think so.

I had a look at the Jet Pac loader and it looks like it uses pretty much all the memory of a 16K machine, to the point where losing the few dozen bytes consumed by a Microdrive channel would stop it working.

I can't see a way of loading Jet Pac from Microdrive on a 16K machine without resorting to compression or something.

[flatduckrecords]

A re-read of the IF1 ROM code suggests that the microdrive channel memory is only claimed when the microdrive is accessed, so it looks to me like there would only be an issue if you did CAT 1, CAT 2, CAT 3, and then tried to load a 16K game. But I'm not sure, there might be a loop in there which claims memory for channels for all attached Microdrives. Does anyone know?

Yeah, when the Spectrum needs to communicate with the Microdrive, the "map" (32 bytes) and "channel" (594 bytes) areas are created.

SAVE, LOAD, VERIFY, MERGE, CAT etc. create "ad-hoc" maps/channels that are reclaimed when the command is finished.

Channels that are OPENed by the user will persist in memory until they've been CLOSEd

Multiple CATs in a row won't eat up more memory. It's used/reclaimed with each one in turn.

See page 32 onwards of Dr Logan's Spectrum Microdrive Book.

I did some tests by looking at the system variables CHANS (end of Microdrive maps and the start of the channels area) and PROG (start of BASIC program area).

• On first boot CHANS and PROG are the same as a normal 16 or 48K Spectrum: 23734 and 23755.
• When the Shadow ROM gets paged in for the first time it creates 58 bytes of new system variables, which shunts CHANS and PROG up by 58 to 23792 and 23813 respectively
• When the user OPENs a stream to a Microdrive file you can see CHANS increasing by 32 bytes to 23824, and PROG shifts up to accommodate those 32 bytes plus another 594 for the channel information taking it to 24440. (Actually I'm off by one here at only 24439, but I guess the 0x80 spacer byte gets added at this point).
• When the stream gets CLOSEd those 627 bytes (32+594+1) are recovered and CHANS, PROG etc move back down. The new system variable persist.

I suppose using MOVE to copy a file between drives would need two channels open, but I wasn't able to test that.

How could Jetpac be loaded…?

To load Jetpac from tape, the loader CLEARs RAMTOP down to 24575—so that doesn't leave enough room to open the Microdrive channel (it would only leave 136 bytes for BASIC, line editor, stack, etc). If you open the channel first, the CLEAR will fail with a "RAMTOP no good" error. You can LOAD in without CLEARing but that will overwrite the stack and crash a 16K machine.

I thought one way to get around this would be to save the game as a CODE block that includes all the system variables and BASIC area (and even the screen, too). That sort of thing works with the tape loading routine becuase it streams the data directly from tape into memory, like loading a snapshot, and execution carries on from where the SAVE command left off. But fails with the Microdrive becuase it needs to fetch and buffer each sector via the CHANS area so we can't just overwrite it, and it's right between the system vars and BASIC. Jetpac also loads a handful of bytes elsewhere (print buffer and system variables). I'm not sure what that's doing so I was kinda ignoring that for now!

But broadly speaking I guess you could at least load in the main 8KB file using a machine code program (in the printer buffer, if it would fit). That way you can move the stack pointer and just ignore the BASIC area…and it might work?

[dfzx]

Lots and lots of details....

And there was me thinking I'd asked a question that was too esoteric even for Spectrum Computing.

Thanks for all that useful information. I'll have another look at the Jec Pac issue, I'd rather given up.

[Stefan]

Look at that loading screen - there's 512 bytes up for grabs at the bottom of it! Add the printer buffer and you have 768 bytes to play around with.

[dfzx]

Look at that loading screen - there's 512 bytes up for grabs at the bottom of it! Add the printer buffer and you have 768 bytes to play around with.

Oh yes, I'm not saying it's not possible. Breaking the loading blocks up and shuffling bits around would definitely allow Jet Pac to load from Microdrive.

The issue originally raised in the German forum was that the original Jet Pac loader can't be easily converted to Microdrive because the 16K machine doesn't have enough memory for the loader plus the extra system variables and channels. The question was asked whether my recreation of the Microdrive expansion system solved such issues. The answer is that it doesn't. I'm 100% compatible, and that means, for better or worse, I suffer all original bugs and limitations. So, er, yay.

[Seven.FFF]

Having an extensible channel mechanism is a wonderful blessing, and in a few cases a lack of extra RAM for the device to use is a bit of a curse. Perhaps extra channels could have been implemented with a fixed sized vector table pointing into extra RAM, in the base model. Overcomplication and extra hardware costs were never the Sinclair way though.

These days you get a bit more of a bang for your hardware buck, so there are mass storage devices with external RAM that leave the original memory map unchanged (unless your NMI button corrupts the stack during a push/pop copy!). They even manage to preserve some sort of compatibility with themselves over time, as some of them have been around for decades now.

Back in the 80s you'd have probably bought a Multiface 1 and saved a Jetpac snapshot to the microdrive. I think that would have loaded on a 16K but you might have had to take the snapshot on a 48K. Or found a way to restore the sysvars and channel table before doing the tape load - the MF had its own ROM routines and RAM to work with the microdrive that didn't rely on the sysvars and channel table. I never had a microdrive but I did use my MF1 with a Rotronics Wafadrive on a 48K.

[Seven.FFF]

Or found a way to restore the sysvars and channel table before doing the tape load

Actually that is quite straightforward. You could connect a MF without IF1, and take a snapshot of a clean 16K boot to the BASIC command line onto tape. Then connect MF, IF1 and microdrive together, boot into the reduced space with the larger channel table, load the snapshot from tape, then load JetPac from tape, then snapshot Jetpac to microdrive. Convoluted, but you only have to do it once per 16K game, and the same process should work for all of them.

[flatduckrecords]

I think that would have loaded on a 16K but you might have had to take the snapshot on a 48K.

I don't have a real 16K to try, but it seems to work under emulation. MF1 uses screen RAM so you get a corrupted picture, but it saves to cartridge correctly and the game remains playable afterwards (i.e. without reloading).

[dfzx]

Back in the 80s you'd have probably bought a Multiface 1 and saved a Jetpac snapshot to the microdrive. I think that would have loaded on a 16K but you might have had to take the snapshot on a 48K.

Edit - gah! Beaten to it... But I've typed it now so I'm going to post it:

Yes, even today it seems that the easiest way to get Jet Pac loading from Microdrive on a 16K machine is to use a Multiface.

FUSE emulates both the Multiface and the Microdrive, and the approach works correctly, both saving the image from a 16K machine and loading it back on a 16K. The MDR cartridge image it produces is compatible with my Microdrive emulator so it all works together rather nicely.

[Seven.FFF]

MF1 uses screen RAM so you get a corrupted picture

For tape snapshots MF1 restores the screen corruption at the end of the load when a MF1 is connected. It's only permanently corrupted if you do a freestanding load. I would think that's the same for microdrive snapshots, but I didn't try it.

They removed the ability to do freestanding snapshot loads on the MF128 and MF3, due to piracy concerns. Although it is possible to hack the snapshots.

You can usually get round the corruption if you take the snapshot right when you are losing a zero-score game, just before it returns to the main menu.

[jpnz]

How could Jetpac be loaded…?

To load Jetpac from tape, the loader CLEARs RAMTOP down to 24575—so that doesn't leave enough room to open the Microdrive channel (it would only leave 136 bytes for BASIC, line editor, stack, etc). If you open the channel first, the CLEAR will fail with a "RAMTOP no good" error. You can LOAD in without CLEARing but that will overwrite the stack and crash a 16K machine.

I thought one way to get around this would be to save the game as a CODE block that includes all the system variables and BASIC area (and even the screen, too). That sort of thing works with the tape loading routine becuase it streams the data directly from tape into memory, like loading a snapshot, and execution carries on from where the SAVE command left off. But fails with the Microdrive becuase it needs to fetch and buffer each sector via the CHANS area so we can't just overwrite it, and it's right between the system vars and BASIC. Jetpac also loads a handful of bytes elsewhere (print buffer and system variables). I'm not sure what that's doing so I was kinda ignoring that for now!

But broadly speaking I guess you could at least load in the main 8KB file using a machine code program (in the printer buffer, if it would fit). That way you can move the stack pointer and just ignore the BASIC area…and it might work?

This is indeed possible...

Spoiler

I wrote some experimental code (13 years ago!) to do this

Currently weighing in at a nasty 220 bytes - a quick check of the last byte of physical RAM, and Jetpac is being loaded from microdrive on a 16K machine:



EDIT: Apart from changing the loading screen filename, all the files are exactly the same as they appear on tape - no compression is used

So much scope for optimization and polish, this code could be adapted for the other 16K Ultimate games...

[XoRRoX]

@jpnz Nice throwback. Nice work

Though if I'm not mistaken, I think people here were discussing how to get it to work on a 16k?

[Stefan]

Though if I'm not mistaken, I think people here were discussing how to get it to work on a 16k?

The video show the last byte of RAM being 32767, which is what a 16K Spectrum has, a 48K Spectrum has an additional 32K at 32768-65535.

[XoRRoX]

The video show the last byte of RAM being 32767, which is what a 16K Spectrum has, a 48K Spectrum has an additional 32K at 32768-65535.

In the code, it writes:

[Stefan]

In the code, it writes:

Ah, in the proof of concept code on old WoS it does, but that was just a PoC for loading from machine code.

[jpnz]

Ah, in the proof of concept code on old WoS it does, but that was just a PoC for loading from machine code.

Yup, spot on! Not much has changed apart from altering the stack pointer and jumping to 24576 to start the game

It's ugly code at best

Anyway, here's an MDR image of the loader minus the 'denienced' Jetpac files

* MOVE can be used to transfer those files onto the cartridge

I moved the files with a 48K model as the 16K didn't cope with the loading screen that well

Important to rename or copy the JPSP file to become /

Why "/" as a filename? It's ASCII code 47 and when incremented will become 48 - "0"

[Redgatemodels]

Hi, looking to get a working copy on my vdrivezx, when you say copy the code do you mean the original Jetpac2, 3, 4, 5 etc?

Any guidance you could give to a numpty like me would be appreciated

[jpnz]

Hi, looking to get a working copy on my vdrivezx, when you say copy the code do you mean the original Jetpac2, 3, 4, 5 etc?

Any guidance you could give to a numpty like me would be appreciated

I guess you have a working cartridge now? I can write up some notes for this 16K version if you like

[Redgatemodels]

I guess you have a working cartridge now? I can write up some notes for this 16K version if you like

Yes thanks, all sorted tucked up on a "ultimate" mdr along with Tranz-Am. Will add a simple basic menu some time.....