"Auto-Hazel"

[dominicbeesley]

I'd appreciate thoughts on this idea I've had - it seems to work but I may be missing something super obvious which might simplify it.

One of the initial aims of the Blitter board project, was to provide a way for Electron/Model B to keep PAGE at E00. I've toyed with a number of ideas but never actually settled down to implement anything until this week.

Aims:
- Maximum compatibility with existing Elk/Model B software
- Should run with original MOS ROM + support BLTUTILS ROM
- Should be simple to port existing FS ROMs without lots of rework
- PAGE=&E00 with ADFS and DFS/MMFS etc present

I've settled on sticking fairly closely to what happens on the Master i.e. Hazel RAM should overlay the MOS at C000-DFFF and the service calls work pretty much as on the Master with extra service calls 21..24 to allocate Hazel.

There are some obstacles though: On the Master the Hazel mapping stays in force "most of the time" except when the MOS fiddles ACCON to page back in the VDU drivers. This would require a modified MOS which I'm trying to avoid if possible, it also means that software that expects to find the font at C000 would instead pick up the current FS's workspace and display rubbish.

To mitigate that problem I've made the Hazel mapping automatic - setting a bit in registers at FE38/FE39 will enable the Hazel mapping for a ROM. Only instructions executed from a ROM with the relevant bit set will see the Hazel memory. Any other instruction will see the MOS ROM. This side-steps the compatibility issues but requires the boot sequence to know which ROMs will require Hazel.

To implement the extra Service calls I've got the BLTUTILs ROM to intercept service call 1 and issue its own service calls 24, 21, 22 for lower priority ROMs and then intercept Service call &FE. The service calls use a modified dispatch routine that checks to see if Y is changed by any ROM (during service calls 24 and 21) and if it does then it has its "auto-hazel" bit set and from that point on any instruction from that ROM will have access to Hazel. [This requires the BLTUTIL rom to be in the top-most slot, but that is pretty much a requirement for other functions anyway]

The API for service call 21 is modified slightly, normally the value for the top of required absolute workspace is passed on to the next lower priority ROM and that ROM will increase it if needed or leave it if not. To detect ROMS that don't require private workspace but do want absolute workspace the service routine resets Y to C0 for each ROM thereby prompting all ROMs to modify Y (so that they can be detected as requiring Hazel). The service routine keeps a track of the maximum itself.

Things to check/fix/improve:
- Test on Electron
- Does the normal OS ROM on the Elk issue service call 1 and FE at the same points in the startup sequence
- The current service call palaver uses some zero page locations in the language workspace (&20 onwards) do I need to save/restore these?
- Check with TUBE
- Are there any FS ROMs that require no private WS but do use absolute?
- The service routine is quite complex and copies itself to the stack, maybe simplify

I've made a modified MMFS as my first test-case at MMFS GitHub Fork which seems after some initial testing to work well and leaves page at E00. If this doesn't seem like an altogether stupid idea and there aren't any better suggestions I'll make DFS, ADFS, HADFS, etc versions [and try to better work out how to make this work with all the MMFS combinations]

The relevant changes to the utility ROM are at BLTUTIL GitHub commit

[BigEd]

Sounds pretty interesting - for the record, because I always forget, HAZEL is the chunk of RAM in high memory, overlaying the OS, which gets used on the Master to provide claimable space for ROMs. Some kind of cleverness is always going to be needed so the RAM can be seen when needed and the ROM can be seen when needed.

Aims:
- Maximum compatibility with existing Elk/Model B software
- Should run with original MOS ROM + support BLTUTILS ROM
- Should be simple to port existing FS ROMs without lots of rework
- PAGE=&E00 with ADFS and DFS/MMFS etc present

(Emphasis added)

[dominicbeesley]

Thanks Ed for pulling out the pertinent bits from my father rambling post!

I've made some progress with ADFS now. It's not super stable but it is a reasonable proof of concept.

D

[cmorley]

This is similar to what my OS RAM does. I stopped work on the manager ROM but I have working ADFS and working DFS1.2 (but not NFS). If I ever do a an OS RAM 2 then I'll add per ROM enables so I don't need to run any enable/disable code on NMIs.

Chris

[dominicbeesley]

I had completely forgotten your OS ram thing....sorry my memory is shocking

Hazel has been on my radar for the Blitter for years but I've finally got round to it and forgot the thread from last year. I'm sure it would have saved me time...I must have got the idea for the service calls from there!

It sounds like the only difference is the 'auto' part, whereby the control ROM detects which client ROMs want high workspace and enable on a per ROM basis. After the service calls the hardware detects writes to fe30 and enables/disables per ROM at that point.

Did you have sources available of your forks of the adfs or dfs targets. I'm about to fold back hoglet's latest updates for adfs157 into the muti-target sources this week and I've not yet chased down the remaining hard-coded E00 references I think as my quick and dirty test with ADFS is a little unstable!

I'll try and make my stuff as compatible as possible and then we can share patched ROMs

If I get the energy together over the coming weeks I'm going to have a cracking at doing a multi target DFS git though that might have to be limited to just 2.2x versions initially (my initial aim will be to get working fast GBPB in to MMFS)

I've now kind of got bogged down trying to write something to backup and restore my ADFS disc to my PC over HostFS/UPURSFS/Beeblink but OSWORD 72 and switching back and forth between filing systems seems to just crash after several cycles...

D

[dominicbeesley]

Good point about NMIs...I just spent an hour and spotted my deliberate mistake. I need the "auto" feature to enable the Hazel RAM if an instruction is running from an enabled ROM _or_ if an NMI routine is running and an enabled ROM is paged in....I wonder are there other situations I'd not thought of. I hadn't twigged from your post about NMIs but I should really have thought of that

The symptoms were that floppy disc accesses in ADFS didn't work (bad directory) but HD was fine.

I've now added an extra bit of logic into the VHDL (checks for instruction fetch from 0Dxx) - this is a bit messy now. However, I'd like to keep it like this for maximum compatibility...

Anyway on the plus-side it forced me to pour over the code and find a few parts of the ADFS sources that had hard-coded accesses of low workspace.

D

[jgharston]

Anyway on the plus-side it forced me to pour over the code and find a few parts of the ADFS sources that had hard-coded accesses of low workspace.

I hope you mopped up afterwards. I'm currently poring over the ENDPROC/ENDFN code in PDP11 BASIC where there's a really fiddly issue stopping local error handing working when a function with a local error handler calls another function with a local error handler, when called within an expression, when the function is in the RHS of the expression.... /that/ took a lot of tracking down to even diagnose!

[dominicbeesley]

I'll see you poring and raise you handing...

D

[tom_seddon]

I've now kind of got bogged down trying to write something to backup and restore my ADFS disc to my PC over HostFS/UPURSFS/Beeblink but OSWORD 72 and switching back and forth between filing systems seems to just crash after several cycles...

At the risk of taking this a bit off topic (please feel free to move discussion elsewhere if you'd rather): the BeebLink disk imager could be suitable, though some self-assembly will be required. (I have a GitHub issue about improving this: https://github.com/tom-seddon/beeblink/issues/96)

The only modification required should be to adfsimage.ts. Comment out the line "return errors.generic(`Bad ADFS image (bad size)`);" in the checkImage function, and restart the server. Then use the imager to do a disk image of the appropriate drive. The Beeb sends the server a copy of the disk descriptor, and the server figures everything out from that, so in theory it should work just as well for hard disks as it does for floppy disks.

The disk imager has proven solid, but it has definitely been tested with a lot more DFS disks than ADFS disks. I'd advise doing "used tracks" mode just to be certain you're getting all the data. (Note: "used tracks" is not the right terminology - this is accurate for DFS disks, but for ADFS it actually does what you'd expect and reads blocks of sectors and lets ADFS figure out any seeking required. Something else for the issues list.)

--Tom

[dominicbeesley]

I hadn't spotted that. Thanks Tom. Is it a *command in rom or one of the utilities....I've been using beeblink on and off recently...I need to devote some time to RTFM?


I'll try and get a look. Does it work in reverse. I.e. to restore the image? Even with original ROMs I seem to end up with broken directories ar bad maps before long and a convenient backup/restore would be great.

D

[tom_seddon]

I hadn't spotted that. Thanks Tom. Is it a *command in rom or one of the utilities....I've been using beeblink on and off recently...I need to devote some time to RTFM?

I'll try and get a look. Does it work in reverse. I.e. to restore the image? Even with original ROMs I seem to end up with broken directories ar bad maps before long and a convenient backup/restore would be great.

It's one of the utilities on the tools volume. The docs for them, such as they are, are here: https://github.com/tom-seddon/beeblink/ ... s/tools.md (the BeebLink docs are worth reading, as they should cover everything, but I'm aware they're not arranged in a very friendly or welcoming manner)

The disk imager works in both directions, and will create image from disk as well as write image to disk.

(I'd be interested to hear how you get on. I've used this for a handful of ADFS L disks but never an actual hard disk. I need to buy a suitable thing for testing with my Master, or add hard disk support to b2 so I can test it in emulation...)

--Tom

[cmorley]

Did you have sources available of your forks of the adfs or dfs targets. I'm about to fold back hoglet's latest updates for adfs157 into the muti-target sources this week and I've not yet chased down the remaining hard-coded E00 references I think as my quick and dirty test with ADFS is a little unstable!

I do yes. Not really had a lot of time for hobbies recently but I'll dig them out. ADFS is stable. DFS1.2 is stable but NFS doesn't work because I didn't fixup the NMI handler.

[dominicbeesley]

Thanks Chris,

Anything you can provide worked be great. I have ADFS and MMFS working well now. I've not attempted DFS yet... I'm tempted to try and do a multi target DFS like I have for ADFS but suspect that it might be more tricky than ADFS.

D