So I patched the PSRAM code and your SD/DMA code with a lock when accessing PSRAM so that both the x86 and nec765 COGs can both perform reads and writes now hopefully without too many issues. Maybe this will be safe for you, but I'm not 100% certain as I've not fully tested it yet. Take a look if you like @macca to see what you think.
I could try to test this with the SD card to see if it still works with PSRAM, but I'll need a DOS image. Would your BIOS be expected to work with more recent DOS's like DOS5? I think I'd have that on a disk lying around here somewhere perahps. What can I do to make an image that will work with your emulator? What minimum set of files does it require? Something like a io.sys, msdos.sys, command.com, config.sys etc, right? It's been ages since I've messed with DOS and am a bit rusty. Is there some tool or command sequence to build a suitable disk image format for your emulator?
@rogloh said:
So I patched the PSRAM code and your SD/DMA code with a lock when accessing PSRAM so that both the x86 and nec765 COGs can both perform reads and writes now hopefully without too many issues. Maybe this will be safe for you, but I'm not 100% certain as I've not fully tested it yet. Take a look if you like @macca to see what you think.
Thank you, I'll look at it.
I could try to test this with the SD card to see if it still works with PSRAM, but I'll need a DOS image. Would your BIOS be expected to work with more recent DOS's like DOS5? I think I'd have that on a disk lying around here somewhere perahps. What can I do to make an image that will work with your emulator? What minimum set of files does it require? Something like a io.sys, msdos.sys, command.com, config.sys etc, right? It's been ages since I've messed with DOS and am a bit rusty. Is there some tool or command sequence to build a suitable disk image format for your emulator?
I don't think it will work with other DOS versions, and in addition the current FDC emulation works only with 180KB disk images, that is 40 tracks, 9 sectors/track, single side (1 head), all linear and there are no checks so anything different will not work. I need to implement a more complete emulation before trying other DOS versions (as soon as I understand how heads and tracks are interleaved).
The PCDOS image should not be difficult to find, try to search "pc dos 2.00 disk image" and one of the first sites should allow to download a .7z file with the images in it. As usual I'm not sure about the legality of such sites, I guess that PCDOS itself is somewhat freely available (Microsoft also released the source code of MSDOS 2.00 wich I think is the original version relabeled by IBM).
@rogloh said:
Oh man, missing out. You'll have to beg, borrow, buy, or build one. Only a single chip PSRAM 6 pins required for 8MB and SOP8 chips are easy to solder.
I now have the thing running in Basic mode (I have to find DOS 2.0 to try the DOS), but why it generates 720x400x70 Hz? For CGA it should be 640x400x60
@pik33 said:
I now have the thing running in Basic mode (I have to find DOS 2.0 to try the DOS), but why it generates 720x400x70 Hz? For CGA it should be 640x400x60
It is 640x400x70 Hz, monitors can't distinguish 720x400 from 640x400 so they report 720x400 (mine do this too).
About the 70 vs. 60 Hz, I can't find the parameters for 60 Hz, several sites reports contraddictory informations (and some have so weird values that I don't believe they are correct even for a second...).
CGA was a 60 Hz thing. MDA/Hercules was 70 Hz but only 350 lines height - I remember these amber monitors with a more readable text (9x14 instead of doubled 8x8)
@pik33 said:
CGA was a 60 Hz thing. MDA/Hercules was 70 Hz but only 350 lines height - I remember these amber monitors with a more readable text (9x14 instead of doubled 8x8)
Yes, I know that, I was talking about the parameters to generate the video with the Propeller...
It might be worth while adding a 8MB chip or 2 on separate 4bit bus for emulating old floppy drives. This way the main psram on a EC32MB could be used for system RAM emulation. This would make for really fast reboot times. Actually HyperFlash would be even better for fast initial boot times...and fast boot times is one reason to emulate these old machines, right? ;^) That is why I loved my hp200lx. It booted in seconds, fast enough to take notes, take down a phone number or set a calendar, long before the smart phones which are always on and suck a lot of battery power spying on you and all of that.
Added an experimental "bus arbiter" cog to serialize the memory access from the devices (CPU and FDC for now) that can implement other memory types such as PSRAM or whatever comes out.
It uses two smartpins in long repository mode to receive requests from the CPU and the FDC and return the results (at least the other day's discussion resulted in something useful...). I have not clear if the corresponding pins can be used for output (I think yes...), maybe one can be used for the beeper.
In the archive I have included a (totally not tested) PSRAM version implemented from @rogloh 's source (hope to not have broken too much...).
The hub-ram performance is not impacted much, hope it is the same for PSRAM. Optimizing this thing will be a challenge... I tought that writes could be left running but it turned out that the FDC is "too fast" and needs an ack signal before sending another write request. I guess that that scratch hub ram write can't be avoided, right ? It is not possible to read the byte directly in a cog register ?
Also added support for 360K and 160/320K disk images (the latter used by CP/M-86) and verified that it can boot other DOS versions... PCDOS 3 works (finally can use KEYBIT to localize the keyboard!) and also CP/M-86 seems to work well, it uses disks with 8 sectors/track instead of 9. I think that other disk sizes like 1,2MB and 1,44MB requires a specific BIOS with selectable disk type options, not a problem for now, the hard disk implementation comes first.
About the disk drives, I noticed that PSRAM uses pins 56 and 57 for clock and CE.. I'm using the same pins to drive the P2-EDGE LEDs to show the drive motor state... really the PSRAM uses the LED pins ? Don't they conflict ?
@Wuerfel_21 said:
The lack of a default setup for P2 is big poo, especially when you start needing a build system with more dependencies than just bash and flexspin
I agree. @Wuerfel_21 since you @rogloh have pushed the hardware like noone else has what would you propose as a DemoBoard platform?
I think I said this before, but ideally it'd just be an Edge carrier with A/V output (probably VGA + 3.5mm jack, maybe pack in an RCA breakout cable to get YPbPr) and USB (multi-device driver when?). Though now with the RAM size proliferation triggered by NeoYume, I guess it maybe needs to have the P2 soldered in alongside a big RAM bank (don't think a higher capacity P2EDGE would really sell enough to justify itself)
I soldered a PSRAM chip to the breakout board "prototype" field, and then with a shortest possible wires to the edge connector pins. No success. 280 MHz, that's all. CLK/4 is needed there.
@pik33 said:
I soldered a PSRAM chip to the breakout board "prototype" field, and then with a shortest possible wires to the edge connector pins. No success. 280 MHz, that's all. CLK/4 is needed there.
@macca said:
Added an experimental "bus arbiter" cog to serialize the memory access from the devices (CPU and FDC for now) that can implement other memory types such as PSRAM or whatever comes out.
Sounds interesting. How many different clients are you expecting? If it stays at just two a shared lock scheme might be better although if you expect other DMA stuff in the future (audio cards?) then it might be better to have a separate arbiter COG in control of this.
I know you're not optimizing yet but if you only have two clients and want to do this:
maybe you can compress down to this? I've not tried it out but I will:
s_loop
mov s_source, #CPU_PIN ' assume CPU request by default after each request returns
rep #2, #0
jse1 #cpu_handler
jse2 #fdc_handler
fdc_handler
mov s_source, #FDC_PIN
cpu_handler ' alias
s_request
...
jmp #s_loop
It uses two smartpins in long repository mode to receive requests from the CPU and the FDC and return the results (at least the other day's discussion resulted in something useful...). I have not clear if the corresponding pins can be used for output (I think yes...), maybe one can be used for the beeper.
Should be doable, or for LED use.
In the archive I have included a (totally not tested) PSRAM version implemented from @rogloh 's source (hope to not have broken too much...).
I'll take a look and see if I can make it work here with PSRAM.
The hub-ram performance is not impacted much, hope it is the same for PSRAM. Optimizing this thing will be a challenge... I tought that writes could be left running but it turned out that the FDC is "too fast" and needs an ack signal before sending another write request. I guess that that scratch hub ram write can't be avoided, right ? It is not possible to read the byte directly in a cog register ?
>
No you really need to read into HUB RAM with the streamer, then read from that. PSRAM with prefetch should help you out a bit with the performance.
Also added support for 360K and 160/320K disk images (the latter used by CP/M-86) and verified that it can boot other DOS versions... PCDOS 3 works (finally can use KEYBIT to localize the keyboard!) and also CP/M-86 seems to work well, it uses disks with 8 sectors/track instead of 9. I think that other disk sizes like 1,2MB and 1,44MB requires a specific BIOS with selectable disk type options, not a problem for now, the hard disk implementation comes first.
I recall needing to do this stuff when I did a port of an SD card to a customized BIOS for a Z80 MicroBee. Lots of different disk geometries and sector skewing stuff for floppies etc. A bit of a pain to sort out but it's only needed once.
@Wuerfel_21 said:
I think I said this before, but ideally it'd just be an Edge carrier with A/V output (probably VGA + 3.5mm jack, maybe pack in an RCA breakout cable to get YPbPr) and USB (multi-device driver when?). Though now with the RAM size proliferation triggered by NeoYume, I guess it maybe needs to have the P2 soldered in alongside a big RAM bank (don't think a higher capacity P2EDGE would really sell enough to justify itself)
How much ram would you go for? Would you just add more chip selects and use the same bus for 0,1,2,3 for 128MB total? Or would you suggest another bus so multiple cogs can hit multiple buses independently? I am guessing the later would be better for emulation but would use almost twice as many pins, total 38 pins for 2 buses with 64MB each. Does it make sense to have a second 4-bit wide bus instead?
@macca said:
Also added support for 360K and 160/320K disk images (the latter used by CP/M-86) and verified that it can boot other DOS versions... PCDOS 3 works (finally can use KEYBIT to localize the keyboard!) and also CP/M-86 seems to work well, it uses disks with 8 sectors/track instead of 9. I think that other disk sizes like 1,2MB and 1,44MB requires a specific BIOS with selectable disk type options, not a problem for now, the hard disk implementation comes first.
I recall needing to do this stuff when I did a port of an SD card to a customized BIOS for a Z80 MicroBee. Lots of different disk geometries and sector skewing stuff for floppies etc. A bit of a pain to sort out but it's only needed once.
There are several implementations of DOS on ROM for embedded systems, including my favorite: http://oldcomputer.info/portables/200lx/index.htm Do they emulate all of the track and sector stuff, or just read the filesystem from ROM at native geometries?
How does DMA work
When a device, such as a floppy disk controller, requests a DMA transfer, it does so by signalling the 8237 on the DRQ (DMA Request) line. The 8237 then signals the processor that it wants to take control of the bus by activating the HRQ (Hold Request) line to the processor. The system waits for the main processor to finish whatever it is doing and then disconnects it from the bus and activates the HOLDA (Hold Acknowledge) line, which causes the processor to be locked out. (The processor is not actually halted, as in the command HLT, merely left idle.) The 8237 takes control of the bus, signals the device that it is ready via the DACK (DMA Acknowledge) line and transfers data to or from the device. When the transfer is completed the DMA is disconnected from the bus, all the lines are reset and the processor is reconnected to the bus and carries out whatever tasks are next demanded of it. The whole process is ready to begin again.
@macca I wonder if your x86 emulator would be able to sort of emulate that same type of HRQ functionality by taking a lock at the beginning of each instruction and releasing it again just before the next instruction is started so it can be potentially be taken by the DMA controller which then does it's thing with the memory arbiter or directly accesses the memory by calling read code inline before releasing it again to let the processor continue with the next instruction?
@macca said:
Added an experimental "bus arbiter" cog to serialize the memory access from the devices (CPU and FDC for now) that can implement other memory types such as PSRAM or whatever comes out.
Sounds interesting. How many different clients are you expecting? If it stays at just two a shared lock scheme might be better although if you expect other DMA stuff in the future (audio cards?) then it might be better to have a separate arbiter COG in control of this.
Not sure, I need to add the hard disk controller but this will be shared with the floppy disk so no additional client, however the DMA has one free channel that may be used for something else, like a sound card. And also was thinking about using it also for I/O requests...
Main problem here is how fast requests can be served. The events from pins can be polled with a single instruction while locks and hub locations requires a more complex polling scheme (acquire the lock, check if a request is really here, do the stuff, ack the request...).
maybe you can compress down to this? I've not tried it out but I will:
s_loop
mov s_source, #CPU_PIN ' assume CPU request by default after each request returns
rep #2, #0
jse1 #cpu_handler
jse2 #fdc_handler
fdc_handler
mov s_source, #FDC_PIN
cpu_handler ' alias
s_request
...
jmp #s_loop
Sounds good, however seems that the rep loop doesn't work for the FDC handler. It works for CPU because the BIOS boot and memory test works, but reads from the FDC fails (either hangs or reports disk boot failure). Adding a nop just below the rep loop (outside the loop itself) works, not sure but seems that jse2 skips the next instruction and the source never gets updated.
This also opens another question... I tought that events and pin states were two different things, but apprently not, with the loop above rdpin ACKs the pin (as it should) and also clears the event... I was expecting that the event remains set until an instruction that explicitly clears it is used (like wait or poll, afaik jse doesn't clear the event) ... never too soon to have a detailed documentation that explains these things...
Late to the party as usual, but I can probably lay my hands on most dos versions if needed.
We also have a number of paid copies of 'rom dos' from Datalight which is a DOS that kept being developed, so it includes the ability to read usb flash drives, works with usb keyboards, has email and networking (ftp etc)
How does DMA work
When a device, such as a floppy disk controller, requests a DMA transfer, it does so by signalling the 8237 on the DRQ (DMA Request) line. The 8237 then signals the processor that it wants to take control of the bus by activating the HRQ (Hold Request) line to the processor. The system waits for the main processor to finish whatever it is doing and then disconnects it from the bus and activates the HOLDA (Hold Acknowledge) line, which causes the processor to be locked out. (The processor is not actually halted, as in the command HLT, merely left idle.) The 8237 takes control of the bus, signals the device that it is ready via the DACK (DMA Acknowledge) line and transfers data to or from the device. When the transfer is completed the DMA is disconnected from the bus, all the lines are reset and the processor is reconnected to the bus and carries out whatever tasks are next demanded of it. The whole process is ready to begin again.
@macca I wonder if your x86 emulator would be able to sort of emulate that same type of HRQ functionality by taking a lock at the beginning of each instruction and releasing it again just before the next instruction is started so it can be potentially be taken by the DMA controller which then does it's thing with the memory arbiter or directly accesses the memory by calling read code inline before releasing it again to let the processor continue with the next instruction?
Currently not, the devices that use the DMA writes or reads as fast as they can, with only the arbiter adding delays if a request is issued while another is currently served.
The CPU is already very slow and adding more delays doesn't seems advisable, I'll see when I add the clock timings to all instructions if there is enough free time left to implement a more correct DMA access. As of now, the fastest 8086 instructions are much slower but on average I expect the P2 to be fast enough to require clock throttling to keep it within the 4.77MHz, this may open the possibility to implement a correct DMA access.
@macca said:
Sounds good, however seems that the rep loop doesn't work for the FDC handler. It works for CPU because the BIOS boot and memory test works, but reads from the FDC fails (either hangs or reports disk boot failure). Adding a nop just below the rep loop (outside the loop itself) works, not sure but seems that jse2 skips the next instruction and the source never gets updated.
Oh, yeah I think I remember evanh mentioning there's an issue with jumps right at the end of a rep loop. Maybe just add a NOP at the end of this loop and rep 3 instructions instead of 2.
This also opens another question... I tought that events and pin states were two different things, but apprently not, with the loop above rdpin ACKs the pin (as it should) and also clears the event... I was expecting that the event remains set until an instruction that explicitly clears it is used (like wait or poll, afaik jse doesn't clear the event) ... never too soon to have a detailed documentation that explains these things...
Yeah welcome to the club. A lot of this sort of thing requires manual experimenting to figure it out...
Currently not, the devices that use the DMA writes or reads as fast as they can, with only the arbiter adding delays if a request is issued while another is currently served.
Yeah this arbiter thing might have to regulate just how much bus access a DMA device gets vs the CPU so you don't starve the CPU. But putting it into another COG, while good for portability/modularity etc to swap in support for other RAM types for example, does introduce even more latency which is not ideal for your emulator.
Had a chance to try out your PSRAM arbiter today, and it seems to work as far as completing the memory check and entering the BASIC interpreter when running with PSRAM. I also believe by using my earlier optimization but with that extra NOP at the end of the REP loop and using a count of 3 instead of 2 fixes the issue you were seeing. I also swapped the CPU and FDC handler order to make sure.
Speaking of the FDC, I still don't have a DOS image yet to try out the FDC, although I was working on a simple boot sector program with nasm to try to display something on the screen as a quick test to show it will load ok, but it didn't work first time I tried so I might have a bug / missed something in my code below. It just went into BASIC at the end of the memory test. I might have an issue with my SD card setup on the P2-Edge with the 58..61 IO pin numbers allocated. Getting SD cards and P2's working together can be problematic...although this one worked with NeoYume. Maybe I should try to read in the floppy data from the binary image itself like you used to do before you added SD card support.
Nasm generates this listing:
1 ORG $7c00
2
3 00000000 B400 mov ah, 0
4 00000002 B003 mov al, 3
5 00000004 CD10 int $10 ; bios call to set video mode to 80x25 colour text (maybe not required here)
6
7 00000006 31C0 xor ax, ax
8 00000008 8ED0 mov ss, ax ; clear stack segment
9 0000000A BC007C mov sp, $7c00 ; setup initial stack below the code
10 0000000D 16 push ss
11 0000000E 07 pop es ; setup es register from stack segment
12 0000000F BE[2600] mov si, strings
13 00000012 E80200 call print ; print the a string pointed to by es:si
14
15 done
16 00000015 EBFE jmp done ; stop here
17
18 print ; repeat printing char's until zero termination character
19 00000017 AC lodsb
20 00000018 08C0 or al, al
21 0000001A 7409 jz return
22 0000001C B40E mov ah, $0e
23 0000001E BB0700 mov bx, 0007
24 00000021 CD10 int $10 ; print a character
25 00000023 EBF2 jmp print ; repeat
26 return
27 00000025 C3 ret
28
29 strings
30 00000026 48656C6C6F00 db "Hello", 0
31
The boot sector binary generated was this which I copied over to PCDOS3_A.IMG and PCDOS3_B.IMG on a uSD card:
00000000 b4 00 b0 03 cd 10 31 c0 8e d0 bc 00 7c 16 07 be |......1.....|...|
00000010 26 7c e8 02 00 eb fe ac 08 c0 74 09 b4 0e bb 07 |&|........t.....|
00000020 00 cd 10 eb f2 c3 48 65 6c 6c 6f 00 |......Hello.|
0000002c
Do the PCDOS3_x.IMG files need to be a full 180kB to work okay or can they be much shorter sized, like the size of the binary shown above? I guess I can pad it out with zeroes or something to test that. Will probably try that next...
UPDATE: also added 55 AA pattern at the end of the 512 byte sector and padded total file size to 180kB. Didn't help, still boots to BASIC only.
@rogloh said:
Had a chance to try out your PSRAM arbiter today, and it seems to work as far as completing the memory check and entering the BASIC interpreter when running with PSRAM. I also believe by using my earlier optimization but with that extra NOP at the end of the REP loop and using a count of 3 instead of 2 fixes the issue you were seeing. I also swapped the CPU and FDC handler order to make sure.
Good! In my code I just added the NOP at the end of the loop without increasing the count, still works.
Do the PCDOS3_x.IMG files need to be a full 180kB to work okay or can they be much shorter sized, like the size of the binary shown above? I guess I can pad it out with zeroes or something to test that. Will probably try that next...
UPDATE: also added 55 AA pattern at the end of the 512 byte sector and padded total file size to 180kB. Didn't help, still boots to BASIC only.
AFAIK, the BIOS doesn't do any check on the boot sector, it just loads sector 1 (0) from track 0 head 0 and jumps to location 7C00H. It jumps to BASIC if there is an error reading from the floppy.
The FDC code does a simple check on the file size to detect the format, altough it should keep the default (360k) if not detected, so I don't think this is the problem. It fails if it can't find the file.
I think you need to add some debug lines to see if the SD card is detected correctly and if the partition is mounted: at the beginning of nec765 code there are calls to sd_init and fs_mount with the relative jumps in case of error, then it tries to open the two floppy images, you can add debug lines there to see if it fails, and also check that after fs_open the file size value is not 0 (which means it can't find the file).
The SD code is from the Catalina library, however I'm not sure which version and if there are later fixes for the shared pins, will check.
@macca said:
I think you need to add some debug lines to see if the SD card is detected correctly and if the partition is mounted: at the beginning of nec765 code there are calls to sd_init and fs_mount with the relative jumps in case of error, then it tries to open the two floppy images, you can add debug lines there to see if it fails, and also check that after fs_open the file size value is not 0 (which means it can't find the file).
Yes, I just added some DEBUG and found I'm getting an SD card init failure (Z flag=0 returned from sd_init). I'm using the P2-Edge built in SD so it mustn't like that even though I know this card works with it and NeoYume. DIP switches are set to flash off, pullup off, pull down off in case that makes a difference to this init path and is known to restrict the SD card somehow..
The SD code is from the Catalina library, however I'm not sure which version and if there are later fixes for the shared pins, will check.
It would be quite handy if this code could support the built in SD card, not one on different pins, otherwise I'll try to hack up a SD card breakout maybe. I think I have something I can use if I can find it.
UPDATE: also just tried this test out with a different 16GB SD card, which is a Sandisk Ultra (grey and red colour) which I think is known to perform better with the P2, and it still failed. The filesystem on it is FAT32.
@macca said:
I think you need to add some debug lines to see if the SD card is detected correctly and if the partition is mounted: at the beginning of nec765 code there are calls to sd_init and fs_mount with the relative jumps in case of error, then it tries to open the two floppy images, you can add debug lines there to see if it fails, and also check that after fs_open the file size value is not 0 (which means it can't find the file).
Yes, I just added some DEBUG and found I'm getting an SD card init failure (Z flag=0 returned from sd_init). I'm using the P2-Edge built in SD so it mustn't like that even though I know this card works with it and NeoYume. DIP switches are set to flash off, pullup off, pull down off in case that makes a difference to this init path and is known to restrict the SD card somehow..
If I'm interpreting the code correctly, it checks for pull-ups and fails if not found, so pullups must be on (I suppose).
You can also comment that code if you want, it is just at the beginning of sd_init (AFAIK is not used anywhere else and doesn't set any flag).
The SD code is from the Catalina library, however I'm not sure which version and if there are later fixes for the shared pins, will check.
It would be quite handy if this code could support the built in SD card, not one on different pins, otherwise I'll try to hack up a SD card breakout maybe. I think I have something I can use if I can find it.
Since as usual I don't have the newest P2-EDGE with SD I can only rely on existing code. When I tried to wire my adapter to the EDGE pins it won't even allow to upload code, I think it is the SD adapter (one of those cheap arduino-target things) but still can't use the same pins.
Comments
So I patched the PSRAM code and your SD/DMA code with a lock when accessing PSRAM so that both the x86 and nec765 COGs can both perform reads and writes now hopefully without too many issues. Maybe this will be safe for you, but I'm not 100% certain as I've not fully tested it yet. Take a look if you like @macca to see what you think.
I could try to test this with the SD card to see if it still works with PSRAM, but I'll need a DOS image. Would your BIOS be expected to work with more recent DOS's like DOS5? I think I'd have that on a disk lying around here somewhere perahps. What can I do to make an image that will work with your emulator? What minimum set of files does it require? Something like a io.sys, msdos.sys, command.com, config.sys etc, right? It's been ages since I've messed with DOS and am a bit rusty. Is there some tool or command sequence to build a suitable disk image format for your emulator?
Thank you, I'll look at it.
I don't think it will work with other DOS versions, and in addition the current FDC emulation works only with 180KB disk images, that is 40 tracks, 9 sectors/track, single side (1 head), all linear and there are no checks so anything different will not work. I need to implement a more complete emulation before trying other DOS versions (as soon as I understand how heads and tracks are interleaved).
The PCDOS image should not be difficult to find, try to search "pc dos 2.00 disk image" and one of the first sites should allow to download a .7z file with the images in it. As usual I'm not sure about the legality of such sites, I guess that PCDOS itself is somewhat freely available (Microsoft also released the source code of MSDOS 2.00 wich I think is the original version relabeled by IBM).
What is the part number for that chip&package?
APS6404L-3SQR-SN
I now have the thing running in Basic mode (I have to find DOS 2.0 to try the DOS), but why it generates 720x400x70 Hz? For CGA it should be 640x400x60
It is 640x400x70 Hz, monitors can't distinguish 720x400 from 640x400 so they report 720x400 (mine do this too).
About the 70 vs. 60 Hz, I can't find the parameters for 60 Hz, several sites reports contraddictory informations (and some have so weird values that I don't believe they are correct even for a second...).
CGA was a 60 Hz thing. MDA/Hercules was 70 Hz but only 350 lines height - I remember these amber monitors
with a more readable text (9x14 instead of doubled 8x8)
Now... this is the ultimate emulation test...
Yes, I know that, I was talking about the parameters to generate the video with the Propeller...
CGA is just standard SDTV timings - remember, actual CGA cards have composite video out
It might be worth while adding a 8MB chip or 2 on separate 4bit bus for emulating old floppy drives. This way the main psram on a EC32MB could be used for system RAM emulation. This would make for really fast reboot times. Actually HyperFlash would be even better for fast initial boot times...and fast boot times is one reason to emulate these old machines, right? ;^) That is why I loved my hp200lx. It booted in seconds, fast enough to take notes, take down a phone number or set a calendar, long before the smart phones which are always on and suck a lot of battery power spying on you and all of that.
Added an experimental "bus arbiter" cog to serialize the memory access from the devices (CPU and FDC for now) that can implement other memory types such as PSRAM or whatever comes out.
It uses two smartpins in long repository mode to receive requests from the CPU and the FDC and return the results (at least the other day's discussion resulted in something useful...). I have not clear if the corresponding pins can be used for output (I think yes...), maybe one can be used for the beeper.
In the archive I have included a (totally not tested) PSRAM version implemented from @rogloh 's source (hope to not have broken too much...).
The hub-ram performance is not impacted much, hope it is the same for PSRAM. Optimizing this thing will be a challenge... I tought that writes could be left running but it turned out that the FDC is "too fast" and needs an ack signal before sending another write request. I guess that that scratch hub ram write can't be avoided, right ? It is not possible to read the byte directly in a cog register ?
Also added support for 360K and 160/320K disk images (the latter used by CP/M-86) and verified that it can boot other DOS versions... PCDOS 3 works (finally can use KEYBIT to localize the keyboard!) and also CP/M-86 seems to work well, it uses disks with 8 sectors/track instead of 9. I think that other disk sizes like 1,2MB and 1,44MB requires a specific BIOS with selectable disk type options, not a problem for now, the hard disk implementation comes first.
About the disk drives, I noticed that PSRAM uses pins 56 and 57 for clock and CE.. I'm using the same pins to drive the P2-EDGE LEDs to show the drive motor state... really the PSRAM uses the LED pins ? Don't they conflict ?
On the P2EDGE-32MB the LEDs are on pins 38/39
Guessed they were moved... ah "compatibility" ... that unknown word!
Well... will change the PSRAM version...
P.S. My Coleco, MSX and Spectrum 128 uses that pins for audio... oh well...
The lack of a default setup for P2 is big poo, especially when you start needing a build system with more dependencies than just bash and flexspin
I agree. @Wuerfel_21 since you @rogloh have pushed the hardware like noone else has what would you propose as a DemoBoard platform?
I think I said this before, but ideally it'd just be an Edge carrier with A/V output (probably VGA + 3.5mm jack, maybe pack in an RCA breakout cable to get YPbPr) and USB (multi-device driver when?). Though now with the RAM size proliferation triggered by NeoYume, I guess it maybe needs to have the P2 soldered in alongside a big RAM bank (don't think a higher capacity P2EDGE would really sell enough to justify itself)
I soldered a PSRAM chip to the breakout board "prototype" field, and then with a shortest possible wires to the edge connector pins. No success. 280 MHz, that's all. CLK/4 is needed there.
Maybe a bypass cap close to the chip would help?
Sounds interesting. How many different clients are you expecting? If it stays at just two a shared lock scheme might be better although if you expect other DMA stuff in the future (audio cards?) then it might be better to have a separate arbiter COG in control of this.
I know you're not optimizing yet but if you only have two clients and want to do this:
s_loop pollse1 wc ' wait client request if_c mov s_source, #CPU_PIN if_c jmp #s_request pollse2 wc ' wait client request if_c mov s_source, #FDC_PIN if_c jmp #s_request jmp #s_loopmaybe you can compress down to this? I've not tried it out but I will:
s_loop mov s_source, #CPU_PIN ' assume CPU request by default after each request returns rep #2, #0 jse1 #cpu_handler jse2 #fdc_handler fdc_handler mov s_source, #FDC_PIN cpu_handler ' alias s_request ... jmp #s_loopShould be doable, or for LED use.
I'll take a look and see if I can make it work here with PSRAM.
>
No you really need to read into HUB RAM with the streamer, then read from that. PSRAM with prefetch should help you out a bit with the performance.
I recall needing to do this stuff when I did a port of an SD card to a customized BIOS for a Z80 MicroBee. Lots of different disk geometries and sector skewing stuff for floppies etc. A bit of a pain to sort out but it's only needed once.
How much ram would you go for? Would you just add more chip selects and use the same bus for 0,1,2,3 for 128MB total? Or would you suggest another bus so multiple cogs can hit multiple buses independently? I am guessing the later would be better for emulation but would use almost twice as many pins, total 38 pins for 2 buses with 64MB each. Does it make sense to have a second 4-bit wide bus instead?
There are several implementations of DOS on ROM for embedded systems, including my favorite: http://oldcomputer.info/portables/200lx/index.htm Do they emulate all of the track and sector stuff, or just read the filesystem from ROM at native geometries?
Reading from this page: http://philipstorr.id.au/pcbook/book2/dma.htm
@macca I wonder if your x86 emulator would be able to sort of emulate that same type of HRQ functionality by taking a lock at the beginning of each instruction and releasing it again just before the next instruction is started so it can be potentially be taken by the DMA controller which then does it's thing with the memory arbiter or directly accesses the memory by calling read code inline before releasing it again to let the processor continue with the next instruction?
Not sure, I need to add the hard disk controller but this will be shared with the floppy disk so no additional client, however the DMA has one free channel that may be used for something else, like a sound card. And also was thinking about using it also for I/O requests...
Main problem here is how fast requests can be served. The events from pins can be polled with a single instruction while locks and hub locations requires a more complex polling scheme (acquire the lock, check if a request is really here, do the stuff, ack the request...).
Sounds good, however seems that the rep loop doesn't work for the FDC handler. It works for CPU because the BIOS boot and memory test works, but reads from the FDC fails (either hangs or reports disk boot failure). Adding a nop just below the rep loop (outside the loop itself) works, not sure but seems that jse2 skips the next instruction and the source never gets updated.
This also opens another question... I tought that events and pin states were two different things, but apprently not, with the loop above rdpin ACKs the pin (as it should) and also clears the event... I was expecting that the event remains set until an instruction that explicitly clears it is used (like wait or poll, afaik jse doesn't clear the event) ... never too soon to have a detailed documentation that explains these things...
Late to the party as usual, but I can probably lay my hands on most dos versions if needed.
We also have a number of paid copies of 'rom dos' from Datalight which is a DOS that kept being developed, so it includes the ability to read usb flash drives, works with usb keyboards, has email and networking (ftp etc)
Currently not, the devices that use the DMA writes or reads as fast as they can, with only the arbiter adding delays if a request is issued while another is currently served.
The CPU is already very slow and adding more delays doesn't seems advisable, I'll see when I add the clock timings to all instructions if there is enough free time left to implement a more correct DMA access. As of now, the fastest 8086 instructions are much slower but on average I expect the P2 to be fast enough to require clock throttling to keep it within the 4.77MHz, this may open the possibility to implement a correct DMA access.
Oh, yeah I think I remember evanh mentioning there's an issue with jumps right at the end of a rep loop. Maybe just add a NOP at the end of this loop and rep 3 instructions instead of 2.
Yeah welcome to the club.
A lot of this sort of thing requires manual experimenting to figure it out...
Yeah this arbiter thing might have to regulate just how much bus access a DMA device gets vs the CPU so you don't starve the CPU. But putting it into another COG, while good for portability/modularity etc to swap in support for other RAM types for example, does introduce even more latency which is not ideal for your emulator.
Hi @macca,
Had a chance to try out your PSRAM arbiter today, and it seems to work as far as completing the memory check and entering the BASIC interpreter when running with PSRAM.
I also believe by using my earlier optimization but with that extra NOP at the end of the REP loop and using a count of 3 instead of 2 fixes the issue you were seeing. I also swapped the CPU and FDC handler order to make sure.
Speaking of the FDC, I still don't have a DOS image yet to try out the FDC, although I was working on a simple boot sector program with nasm to try to display something on the screen as a quick test to show it will load ok, but it didn't work first time I tried so I might have a bug / missed something in my code below. It just went into BASIC at the end of the memory test. I might have an issue with my SD card setup on the P2-Edge with the 58..61 IO pin numbers allocated. Getting SD cards and P2's working together can be problematic...although this one worked with NeoYume. Maybe I should try to read in the floppy data from the binary image itself like you used to do before you added SD card support.
Nasm generates this listing:
1 ORG $7c00 2 3 00000000 B400 mov ah, 0 4 00000002 B003 mov al, 3 5 00000004 CD10 int $10 ; bios call to set video mode to 80x25 colour text (maybe not required here) 6 7 00000006 31C0 xor ax, ax 8 00000008 8ED0 mov ss, ax ; clear stack segment 9 0000000A BC007C mov sp, $7c00 ; setup initial stack below the code 10 0000000D 16 push ss 11 0000000E 07 pop es ; setup es register from stack segment 12 0000000F BE[2600] mov si, strings 13 00000012 E80200 call print ; print the a string pointed to by es:si 14 15 done 16 00000015 EBFE jmp done ; stop here 17 18 print ; repeat printing char's until zero termination character 19 00000017 AC lodsb 20 00000018 08C0 or al, al 21 0000001A 7409 jz return 22 0000001C B40E mov ah, $0e 23 0000001E BB0700 mov bx, 0007 24 00000021 CD10 int $10 ; print a character 25 00000023 EBF2 jmp print ; repeat 26 return 27 00000025 C3 ret 28 29 strings 30 00000026 48656C6C6F00 db "Hello", 0 31The boot sector binary generated was this which I copied over to PCDOS3_A.IMG and PCDOS3_B.IMG on a uSD card:
Do the PCDOS3_x.IMG files need to be a full 180kB to work okay or can they be much shorter sized, like the size of the binary shown above? I guess I can pad it out with zeroes or something to test that. Will probably try that next...
UPDATE: also added 55 AA pattern at the end of the 512 byte sector and padded total file size to 180kB. Didn't help, still boots to BASIC only.
Good! In my code I just added the NOP at the end of the loop without increasing the count, still works.
AFAIK, the BIOS doesn't do any check on the boot sector, it just loads sector 1 (0) from track 0 head 0 and jumps to location 7C00H. It jumps to BASIC if there is an error reading from the floppy.
The FDC code does a simple check on the file size to detect the format, altough it should keep the default (360k) if not detected, so I don't think this is the problem. It fails if it can't find the file.
I think you need to add some debug lines to see if the SD card is detected correctly and if the partition is mounted: at the beginning of nec765 code there are calls to sd_init and fs_mount with the relative jumps in case of error, then it tries to open the two floppy images, you can add debug lines there to see if it fails, and also check that after fs_open the file size value is not 0 (which means it can't find the file).
The SD code is from the Catalina library, however I'm not sure which version and if there are later fixes for the shared pins, will check.
Yes, I just added some DEBUG and found I'm getting an SD card init failure (Z flag=0 returned from sd_init). I'm using the P2-Edge built in SD so it mustn't like that even though I know this card works with it and NeoYume. DIP switches are set to flash off, pullup off, pull down off in case that makes a difference to this init path and is known to restrict the SD card somehow..
It would be quite handy if this code could support the built in SD card, not one on different pins, otherwise I'll try to hack up a SD card breakout maybe. I think I have something I can use if I can find it.
UPDATE: also just tried this test out with a different 16GB SD card, which is a Sandisk Ultra (grey and red colour) which I think is known to perform better with the P2, and it still failed. The filesystem on it is FAT32.
If I'm interpreting the code correctly, it checks for pull-ups and fails if not found, so pullups must be on (I suppose).
You can also comment that code if you want, it is just at the beginning of sd_init (AFAIK is not used anywhere else and doesn't set any flag).
Since as usual I don't have the newest P2-EDGE with SD I can only rely on existing code. When I tried to wire my adapter to the EDGE pins it won't even allow to upload code, I think it is the SD adapter (one of those cheap arduino-target things) but still can't use the same pins.