exidysorcerer.net

There's also a document with a print version of the layout:
I've been blindly testing some things. I've checked that right after booting the machine with SCUAMON 3.4, I've RAM in the first 3 16KB banks as expected, I was feared that some misconfiguration affected the memory map when ESGG monitor is not in control.

Also, outputting some values to port 7Fh (OU 7F n) always caused a hang except 0 value; so seems that I need to check this moving the stack just in case the swapped page (if any) is the one with the stack. A warm start brings me back the prompt; but also probably, restores the original paging as I can't see any changes in the poked values.

Abzman wrote: ↑Wed Mar 27, 2024 3:18 pm what sort of hacks are going on to get the 28 pin 2764 chips into the 24 pin spots on both the motherboard and the ram board? I don't think it'll end up being super important, I'm just interested now.

That's my fault!. Original PCB EPROMs are 2732 that perfectly fit into the 24pin sockets. As I don't have right now 2732s, I've been using some 2764 ones with a underlaying socket with the needed mods, VCC relocated and A12 wired to ground (for now, later I'll think if I add a bank switch).
In every half of the EPROM I've the same SCUAMON+1.0 binary.

The original EPROMs have their 4KB space filled with the 1.3B + 1.0 monitors, first halves in the EXTRAMDSK PCB and second halves in the main motherboard socket (2E).

The lack of a way to switch between monitors, enabling/disabling A11 in both EPROMs (1E & 2E) also puzzles me...

Well, 1.1 does make the power traces bigger and add more bulk capacitance. I think A11 has to be controlled on a hack on the motherboard somewhere. Could it be one of those thin blue wirewrap wires?

I also built up a replica of 1.1, I like the trace layout better. I'm still trying to wrap my head around how a DRAM refresh circuit works so I've not completely grasped how this, or even the original Sorcerer RAM system works yet.

Also, outputting some values to port 7Fh (OU 7F n) always caused a hang except 0 value; so seems that I need to check this moving the stack just in case the swapped page (if any) is the one with the stack. A warm start brings me back the prompt; but also probably, restores the original paging as I can't see any changes in the poked values.

Writing any value to the control port other than 0 (without copying the stack to the different banks) will crash the system

Ramdisk program runs either in the $FC00 space, or from a RAM PAK in the $C000-$DFFF space.

I have a (corrupted) copy of the source code (courtesy Exidyboy) for the ram disk program which I'm trying to rebuild. Stay tuned.

exidyboy may be able to help with a disk image which contains the programs?

Cheers,
Leslie

Hi All,

Files courtesy exidyboy.

Had to go through a batch of different executables to rebuild one to match the source code.

Cheers,
Leslie

Thanks to the binaries posted above and some help from ChickenMan I've executed the tool and this is what I get:


Sure, I don't have the RAM PAC, no 56KB are available

After reading parts of the code, my first thought has been to declare the BOOTST variable as 1 to set the bootstrap start address in the 48K RAM area; but setting the defaults inside EXRAMDSK seems to not work as it fails when saving the defaults file into the SD (I'm using a Gotek with FlashFloppy firmware). Don't know if FlashFloppy enables writing the Sorcerer disks or the file saving routine in EXTRAMDSK is hardcoded for a specified format not compatible with the Dreamdisk one.

So as a last resort, I've modified the binary with an hex editor and initially set to 1 the variable; but when trying to install the RAM disk, it still fails with the "No RAM Pack" error. I'll try to reformat the source code to be able to modify, compile and check if it really needs 56KB to work.

jltursan wrote: ↑Sun Apr 07, 2024 4:03 pm Don't know if FlashFloppy enables writing the Sorcerer disks or the file saving routine in EXTRAMDSK is hardcoded for a specified format not compatible with the Dreamdisk one.

Have you been unable to write to a Gotek or a real floppy disk using the Dreamdisk in general or just in the specific case above?

jltursan wrote: ↑Sun Apr 07, 2024 4:03 pm So as a last resort, I've modified the binary with an hex editor and initially set to 1 the variable; but when trying to install the RAM disk, it still fails with the "No RAM Pack" error. I'll try to reformat the source code to be able to modify, compile and check if it really needs 56KB to work.

I tried running the unmodified .COM file from RedSkullDC in MAME but it runs off into the weeds. I am doing this to get an in-focus screen shot to share with Floor.

Can I ask you to either:
a) post a more readable photo of the screen
b) post your edited binary
or
c) let me know which byte(s) you edited with a hex editor to get it to run in at least as far as the title screen in a 48K machine.

Thanks

Hey, sure!, sorry for the sloppy response...

The byte to modifiy is this one:


Here's also the binary already patched:
Setting it to 1, the bootstrap will be allocated in $BF00

I'll post a new pic ASAP...

Nah, my skills as a photographer are below nil...

This is the best I can get:


It's the message shown after executing "EXRAMDSK C", so initializing and formatting the RAM disk. Seems that the expected RAM pack is not detected.

Hi everybody. I'm Dutch so I can read and translate the Dutch text into English. Give me some time though. As I'm working on my Sorcerers to get them working. And making an index in English of the ESGG newsletters. Intended for Exidyboy but also no problem to put it here on the website for everybody to read. Maybe with AI it's possible to convert the Dutch Newsletters, not printed but stencilled to reduce the cost, to a Word file or ODF format to be able to automatically translate it into English.

I know the ESGG RAMDISK extension project but I didn't convert my heavily modified Sorcerer C2 to use it as I moved on to a PC in that time.