Thanks for your view on DRAM. If you consider it to be so much trouble, then I am probably not going to get that far.
On the real Z80 the DRAMs used so many extra chips such as buffers, multiplexers and delays that often the outnumbered the DRAMs. When Dr_A came up with the DracBlade memory system it seemed like the same thing all over again, in reverse. I just thought that to bolt on one single chip as the memory would be a sort of "payback time".
Oh for an interupt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby Seckshund said...
Thanks for your view on DRAM. If you consider it to be so much trouble, then I am probably not going to get that far.
Actually it should be about as complicated as DracBlade's RAM address scheme, perhaps a little more complicated. I just fear I won't be able to desolder one of these SDRAM chips and put it to my PropRPM board with wires to be able to test such a setup. You can of course try to do this on your side and just add the core rd_byte/wr_byte functions to match your hardware...
I was using your scepticium as a warm blanket of excuse. Then you go and say it should be ok.
I have steamed off (hot air) a bunch of chips to persecute. The old EDO ones are even 50mil, bless.
The test bed will not run the latest DracBlade software, at pesent, but seems ok with the older stuff.
It's a difference if you want _me_ to add support for EDO/SDRAM, or if you try it yourself
I would have tried it, if the hardware was easier to handle.
Right now I'm searching for the cause why the combined SPI/XMM driver won't run together with the VGA object. It seems the SD card can't be read anymore.
I didn't get too much time to hunt the problem with the latest SD code. I saw that the parameter "Basepin" was quoted in both the SD and VGA code blocks, they might be local, rather than public, but I didn't get to see where the SD code picked up the start pin of the·SD but then goes on to "Basepin + 1, ....". I ran a search through the whole code too.
I'll have another look tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby, basepin isn't used in the current SD card code. All the initialisation is done using the start_explicit pub. Follow the startup through from FindSDBlock in Main_Dr_acula.spin, that calls memm.mount_explicit(spiDO, spiCLK, spiDI, spiCS) to mount the sd card and start the mb_spi_small.spin pasm code in a new cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
Toby, basepin isn't used in the current SD card code. All the initialisation is done using the start_explicit pub. Follow the startup through from FindSDBlock in Main_Dr_acula.spin, that calls memm.mount_explicit(spiDO, spiCLK, spiDI, spiCS) to mount the sd card and start the mb_spi_small.spin pasm code in a new cog.
Still no luck with the VGA / XMM+SPI combination. Perhaps you can give it a try? The new code v0.9.1 is at the first page. I tried to move the code around in order to shift possible memory corruption, but it didn't help. The "r" command for the first block of A.DSK returns an error with the VGA object linked in. It works with my TV80 object, which uses just 1 of the VGA/TV pins.
BTW I renamed the object to DracBlade_mb_small_spi.spin because I plan to make similar objects for the other platforms. I also stripped some commented code (from pasting the read/write inline) and unused variables to better see what's actually in there and what isn't.
Cluso99 said...
Drac: Where is the latest VT100 that works with Wordstar. I would like to know what could be stripped from it as maybe I could fit (optimistically???) it into my 1-pin TV driver
BTW you will definitely get eye cancer from looking at that piece of code. I was just lucky that my glasses were so dirty they filtered most of the evil rays shining from this code The "error handling" for the wrongly calculated row offset just looks like the devil himself wrote it. I'd rather take a look at e.g. the Linux console code which has a nice VT100 emulation. Actually my vt100.spin is based off the constants found in this source and an x86 assembler implementation I wrote some years ago.
I note the picture on the dracblade thread. I downloaded version 9.3 but a file is missing
fat : "fatfs"
Is this the complete package?
Addit: It is in the zip file, now which directory did it get unzipped to...
ok found it, but the 'fatfs' is your fat version, and is the problem with this one or with hairymnstrs one?
Actually I'm confused again as to what is the problem and with what code. Can you post another package of files again? I'd like to explore this possibility of supply currents and the sd card.
addit:
I have this on the terminal coming out of port1
Dr_Acula said...
I've missed a bit of progress as I had to sleep.
That's one of the negative aspects of being a human
FAT32 ought to work as well as FAT16. I had tested both some time ago.
Anyway, glad to see it worked for you.
As for the fg/bg colour port: don't you think that (ab-)using a VT100 escape sequence would make more sense? To make a connection from the I/O port object to the VGA object actually requires a lot of code, because they don't share any variable pointers except the rendezvous long as of yet. If we just defined another set of (incompatible) values for the <ESC>[noparse][[/noparse]...m attributes sequence you could change the screen colours by printing a few characters.
Or, since we do not have per character attributes anyway, we could just use the most recent fg/bg colour attributes for the entire screen instead of just for the following text output. That would be <ESC>[noparse][[/noparse]30-37m for the foreground colour and <ESC>[noparse][[/noparse]40-47m for the background, and you could specify both in one string separating the numbers by a semicolon.
ESC [noparse][[/noparse] 30 m Foreground black
ESC [noparse][[/noparse] 31 m Foreground red
ESC [noparse][[/noparse] 32 m Foreground green
ESC [noparse][[/noparse] 33 m Foreground yellow
ESC [noparse][[/noparse] 34 m Foreground blue
ESC [noparse][[/noparse] 35 m Foreground magenta
ESC [noparse][[/noparse] 36 m Foreground cyan
ESC [noparse][[/noparse] 37 m Foreground white
ESC [noparse][[/noparse] 40 m Background black
ESC [noparse][[/noparse] 41 m Background red
ESC [noparse][[/noparse] 42 m Background green
ESC [noparse][[/noparse] 43 m Background yellow
ESC [noparse][[/noparse] 44 m Background blue
ESC [noparse][[/noparse] 45 m Background magenta
ESC [noparse][[/noparse] 46 m Background cyan
ESC [noparse][[/noparse] 47 m Background white
Yes, I have them decoded in vt100.spin, it's just that we have no other attributes but character line bg/fg colours. I could just change the cursor line's colour for now.
The new version 0.9.10 is in preparation for running MP/M. The console #0 in-/output is split from the keyboard in- and VGA or TV80 output. The latter two are console #1 now (ports $14, $15). The second serial connection is console #2 (ports $16, $17). The LCD text output is punch data ($13) and the LCD instructions is punch status/control ($12).
Do you run CP/M then run MP/M (either manually or as a SUBMIT file)?
If booting into CP/M, what is the local keyboard connected to before MP/M runs? Does it connect to CP/M so you can run MP/M?
The first console (and only console for CP/M) is on SIO #0. I run MPM.COM manually from CP/M.
The keyboard is not used in CP/M, except it is accessible by ports $14 (status) $15 (input/output).
MP/M still doesn't work under qz80 on the DracBlade. The same files work under SIMH, so it has to be some bug in console status or data handling. I don't see this bug debugging the I/O activity, though. You should be able to DO SYSMPM if you change MPMXIOS.MAC on the disk. If you get it working, please let us know!
Whatever it was, it's gone away now. MP/M II runs on the Dracblade! TV80 is showing the login on user 1 drive A.
Grr.. and now it does not again. This has to be a uninitialized variable type of bug.
1) Download the latest version from page 1.
2) Copy all the files in the \lib directory into the \qz80 directory.
3) Put a copy of BST in the \qz80 directory
4) Run BST. Change the menu from my working menu to the new Juergen file directory (renamed 19th April). Open cpm.spin
5) Edit the following lines
#define HAVE_VGA
vgaPin = 16
' TV pins on the DracBladeProp - 16-19; use 18 for the 1 pin TV out
'#define HAVE_TV
tvPin = 16
uncomment #define HAVE_VGA
comment #define HAVE_TV
but leave tvPin as a constant otherwise errors in another part of the program
6) In io.spin change the baud rate to 57600 (I can't seem to run any faster due to a long cable, BUT this is still much faster than the current dracblade code which cannot run faster than 19200. Already the Pullmoll code is looking very good!)
7) Compile with F11
8) Open teraterm with settings for serial port COM1 and baud 57600 (save these settings and make them default)
vga screen will remain blank, also LCD screen is blank. All input/output is via port 1 on the dracblade.
9) Use a sandisk 1Gb sd card formatted with fat16 (we know other brands work with fat32 using hairmnstrs code)
10) Note just to me - Juergen's sd card has the label upside down.
11) Put A.DSK on the sd card from page 1 of this thread. Copy a blank drive onto the sd card and make 7 copies named B.DSK to H.DSK
12) Reboot with Teraterm running
13) Run MP/M
@Juergen, I may have found it (not sure, haven't tried it and only briefly read your code).
Do you reset the high address latch (command "H", 0) at boot, I couldn't see it in your code, if not then where the bootloader gets put in RAM is wherever the 374 is pointing at power up/reset from last run which would be why it sometimes works and sometimes doesn't.
I'll look more this evening when I get home.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
@Juergen, I may have found it (not sure, haven't tried it and only briefly read your code).
Do you reset the high address latch (command "H", 0) at boot, I couldn't see it in your code, if not then where the bootloader gets put in RAM is wherever the 374 is pointing at power up/reset from last run which would be why it sometimes works and sometimes doesn't.
I'll look more this evening when I get home.
Yes, the boot code does it by setting the bank to 0 when banking is supported.
The code in hdsk_setup_dma in io.spin then always sets the high latch to 0.
BTW banking works in principle. I can go and assemble the folllowing lines in CP/M using DDTZ:
>a100
>100 LD A,0C
>102 OUT (0FE),A
>104 LD A,01
>106 OUT (0FE),A
>108 .
>B 108
>G 100
...
A>
This switched to bank 1 and then leads to booting CP/M again, because the banked code vanished.
Now if I enter almost the same code again, except changing the LD A,01 to LD A,00, I can switch back to bank 0 without rebooting CP/M, because the same program is in memory and the stack is in the common area. I then can go in each bank switching to the other back and forth.
hairymnstr said...
okay. I've been reading the xios.mac code a bit but not got very deep yet, don't know enough about the CP/M bios jump table calls.
It _should_ work, because it works under SIMH. If you try the A.DSK instead of the i.dsk by modifying Dr_A's "mpm" file with the setup for SIMH, you can go to drive I: and run MPM from there. Afterwards you don't have any diskette drive, but just the hard disk drive, so it's working as expected.
The bug in my code has to be triggered inside MP/M, probably not inside the XIOS.
What I wanted to try is to add some debug output to each XIOS function, so I can see what gets called and what is the last action before it hangs.
Edit: What sometimes works a little different is loading MPM.COM into DDTZ and running it from there, i.e. DDTZ MPM.COM and G. Then I get an Bdos Err On A: Bad Sector. Bdos Function: 15 File: $0$.SUP and an 0A> prompt. Entering DIR doesn't find DIR.PRL, though.
hairymnstr said...
Sounds like a logical next step.
Just as a minor bug report, if you comment out #define HAVE_LCD io.spin causes errors on compilation.
Fixed in 0.9.13.
I would love to know what causes the Chopper game to hang with the TRS80 emulation, because that's most probably the same bug that MP/M hits - or at least it's a definite bug in qz80.
It has to be an 8080/8085 opcode, because MP/M is not using Z80 opcodes at all. I should actually try to run it all with q85.spin, adding the banking code in there, too.
When I was working on the original zicog code there were some bugs that were hard to find, and heater had left some code that printed out half the registers. I modified it and added all the registers. Then used the 'single stepping' flag and ran the code till it crashed. There simply was no other way to find some bugs, especially ones that happen some time after a program starts. Is there a way to add this code to the qZ80 and then just set it running, printing out the registers for every instruction? Can this be done in spin or does it need translating to pasm?
PRI print_regs
'Print the Z80 registers
RegString(string("AF ="))
HexOutput(af_reg)
RegString(string(" BC ="))
HexOutput(bc_reg)
RegString(string(" DE ="))
HexOutput(de_reg)
RegString(string(" HL ="))
HexOutput(hl_reg)
RegString(string(" SP ="))
HexOutput(sp_reg)
RegString(string(" PC ="))
HexOutput(pc_reg)
RegString(string(13,10)) ' new line for alternate register
RegString(string("AF'="))
HexOutput(af_reg_alt)
RegString(string(" BC'="))
HexOutput(bc_reg_alt)
RegString(string(" DE'="))
HexOutput(de_reg_alt)
RegString(string(" HL'="))
HexOutput(hl_reg_alt)
RegString(string(" IX ="))
HexOutput(ix_reg)
RegString(string(" IY ="))
HexOutput(iy_reg)
RegString(string(13,10))
Dr_Acula said...
Thanks for the hint re compiler search paths.
When I was working on the original zicog code there were some bugs that were hard to find, and heater had left some code that printed out half the registers. I modified it and added all the registers. Then used the 'single stepping' flag and ran the code till it crashed. There simply was no other way to find some bugs, especially ones that happen some time after a program starts. Is there a way to add this code to the qZ80 and then just set it running, printing out the registers for every instruction? Can this be done in spin or does it need translating to pasm?
There is an i/o command "break" that does the same as in ZiCog. It was originally executed when a HALT command was hit, but with interrupt code enabled HALT has to do what it is supposed to do. I can still execute break at some point in qz80, though.
I had a bug in the counterpart of the break in io.spin that is fixed now. I already tried what you suggested. Unfortunately tracing the MP/M code with real time interrupts (50 per second) is impossible, since it does nothing but go to the interrupt routine and overflow the stack with return addresses this way. This is to be expected, because tracing is too slow to handle real time events. I would have to create the interrupts at a much lower rate, or ideally bound to a rate that depends on the traced code's execution speed, i.e. the cycle count of the Z80.
I think I can try with a rate of 1 per second or 1 every couple of seconds and try tracing again.
FYI: MP/M works now. At least the console #0 does, not sure about console #1 (keyboard) or console #2 (sio #1).
The bug was in the code that did read the interrupt request. I used t1 there while I should have used tmp, which is what do_interrupt tests for the type of interrupt and vector. DUH!
I think I have to do something to the *.PRL files to make them accessible by everyone. If you enter "user 1" you are booby-trapped now, because there is no executable command. I'll try to "stat *.PRL $sys" or similar to set the system flag on the PRL files. Does anyone know if this should make them accessible for everyone? Edit: Yes, it looks that is required, so you should do it on the A.DSK I supplied.
I lowered the interrupt rate to 20 ticks / second to not waste too much time in the interrupt handler. If you want to try with 50 again (it worked), you have to run gensys and change the setting and also edit mpmxios.mac and set the "ticks equ 20" there.
I also limited the number of hard disks to 4 to save some shared memory. It doesn't help too much for user 0. In MBASIC you have only 19KB free and Wordstar has not enough memory to do anything. If you want to have all 8 hard disks again, edit MPMD.LIB and change the "nhdisks equ 4" line. Afterwards you "DO SYSMPM" to build a new MP/M.
Finally you should be able to include the 8085 core instead of Z80 now. I have to try it again - must disable the Z80 in gensys first, because otherwise the MP/M dispatcher is trying to save the Z80 alternate register set which doesn't work on the 8085. There's a "#define CPU_8085" in cpm.spin which you can enable instead of the "#define CPU_Z80".
Edit: Building MP/M (DO SYSMPM) is possible only with the Z80 core, because the SUB-file runs ddtz.
Here is a helpful link to a CP/M and MP/M handbook PDF.
PulMol: WOW Fantastic. MP/M on the Prop. One of my long term dreams has come true. Well done. Shame I have to be doing so much "real work" now a days. I want to play[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Thanks for your view on DRAM. If you consider it to be so much trouble, then I am probably not going to get that far.
On the real Z80 the DRAMs used so many extra chips such as buffers, multiplexers and delays that often the outnumbered the DRAMs. When Dr_A came up with the DracBlade memory system it seemed like the same thing all over again, in reverse. I just thought that to bolt on one single chip as the memory would be a sort of "payback time".
Oh for an interupt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Actually it should be about as complicated as DracBlade's RAM address scheme, perhaps a little more complicated. I just fear I won't be able to desolder one of these SDRAM chips and put it to my PropRPM board with wires to be able to test such a setup. You can of course try to do this on your side and just add the core rd_byte/wr_byte functions to match your hardware...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I was using your scepticium as a warm blanket of excuse. Then you go and say it should be ok.
I have steamed off (hot air) a bunch of chips to persecute. The old EDO ones are even 50mil, bless.
The test bed will not run the latest DracBlade software, at pesent, but seems ok with the older stuff.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
It's a difference if you want _me_ to add support for EDO/SDRAM, or if you try it yourself
I would have tried it, if the hardware was easier to handle.
Right now I'm searching for the cause why the combined SPI/XMM driver won't run together with the VGA object. It seems the SD card can't be read anymore.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I'll have another look tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Still no luck with the VGA / XMM+SPI combination. Perhaps you can give it a try? The new code v0.9.1 is at the first page. I tried to move the code around in order to shift possible memory corruption, but it didn't help. The "r" command for the first block of A.DSK returns an error with the VGA object linked in. It works with my TV80 object, which uses just 1 of the VGA/TV pins.
BTW I renamed the object to DracBlade_mb_small_spi.spin because I plan to make similar objects for the other platforms. I also stripped some commented code (from pasting the read/write inline) and unused variables to better see what's actually in there and what isn't.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
BTW you will definitely get eye cancer from looking at that piece of code. I was just lucky that my glasses were so dirty they filtered most of the evil rays shining from this code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/12/2010 6:51:45 PM GMT
I note the picture on the dracblade thread. I downloaded version 9.3 but a file is missing
fat : "fatfs"
Is this the complete package?
Addit: It is in the zip file, now which directory did it get unzipped to...
ok found it, but the 'fatfs' is your fat version, and is the problem with this one or with hairymnstrs one?
Actually I'm confused again as to what is the problem and with what code. Can you post another package of files again? I'd like to explore this possibility of supply currents and the sd card.
addit:
I have this on the terminal coming out of port1
and random ascii characters on the vga with yellow on blue text...
I just remembered my hairymnstr sd card is fat32. Swapping back to a fat16 one...
Ok, vga disabled and booting into CP/M ok
vga enabled again. Boots the same on the terminal and on the screen... see attached photo.
All working brilliantly!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/13/2010 12:35:10 AM GMT
That's one of the negative aspects of being a human
FAT32 ought to work as well as FAT16. I had tested both some time ago.
Anyway, glad to see it worked for you.
As for the fg/bg colour port: don't you think that (ab-)using a VT100 escape sequence would make more sense? To make a connection from the I/O port object to the VGA object actually requires a lot of code, because they don't share any variable pointers except the rendezvous long as of yet. If we just defined another set of (incompatible) values for the <ESC>[noparse][[/noparse]...m attributes sequence you could change the screen colours by printing a few characters.
Or, since we do not have per character attributes anyway, we could just use the most recent fg/bg colour attributes for the entire screen instead of just for the following text output. That would be <ESC>[noparse][[/noparse]30-37m for the foreground colour and <ESC>[noparse][[/noparse]40-47m for the background, and you could specify both in one string separating the numbers by a semicolon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/13/2010 2:37:40 AM GMT
I will see if I have a manual at home.
My books are buried behind a lot of stuff but a quick Google search found the following:
http://www.tau.ac.il/cc/internal/X-terminals/6-3-1-4.html
ESC [noparse][[/noparse] 30 m Foreground black
ESC [noparse][[/noparse] 31 m Foreground red
ESC [noparse][[/noparse] 32 m Foreground green
ESC [noparse][[/noparse] 33 m Foreground yellow
ESC [noparse][[/noparse] 34 m Foreground blue
ESC [noparse][[/noparse] 35 m Foreground magenta
ESC [noparse][[/noparse] 36 m Foreground cyan
ESC [noparse][[/noparse] 37 m Foreground white
ESC [noparse][[/noparse] 40 m Background black
ESC [noparse][[/noparse] 41 m Background red
ESC [noparse][[/noparse] 42 m Background green
ESC [noparse][[/noparse] 43 m Background yellow
ESC [noparse][[/noparse] 44 m Background blue
ESC [noparse][[/noparse] 45 m Background magenta
ESC [noparse][[/noparse] 46 m Background cyan
ESC [noparse][[/noparse] 47 m Background white
Yes, I have them decoded in vt100.spin, it's just that we have no other attributes but character line bg/fg colours. I could just change the cursor line's colour for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Do you run CP/M then run MP/M (either manually or as a SUBMIT file)?
If booting into CP/M, what is the local keyboard connected to before MP/M runs? Does it connect to CP/M so you can run MP/M?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The first console (and only console for CP/M) is on SIO #0. I run MPM.COM manually from CP/M.
The keyboard is not used in CP/M, except it is accessible by ports $14 (status) $15 (input/output).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/17/2010 2:28:40 PM GMT
Whatever it was, it's gone away now. MP/M II runs on the Dracblade! TV80 is showing the login on user 1 drive A.
Grr.. and now it does not again. This has to be a uninitialized variable type of bug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/17/2010 4:12:19 PM GMT
1) Download the latest version from page 1.
2) Copy all the files in the \lib directory into the \qz80 directory.
3) Put a copy of BST in the \qz80 directory
4) Run BST. Change the menu from my working menu to the new Juergen file directory (renamed 19th April). Open cpm.spin
5) Edit the following lines
#define HAVE_VGA vgaPin = 16 ' TV pins on the DracBladeProp - 16-19; use 18 for the 1 pin TV out '#define HAVE_TV tvPin = 16uncomment #define HAVE_VGA
comment #define HAVE_TV
but leave tvPin as a constant otherwise errors in another part of the program
6) In io.spin change the baud rate to 57600 (I can't seem to run any faster due to a long cable, BUT this is still much faster than the current dracblade code which cannot run faster than 19200. Already the Pullmoll code is looking very good!)
7) Compile with F11
8) Open teraterm with settings for serial port COM1 and baud 57600 (save these settings and make them default)
vga screen will remain blank, also LCD screen is blank. All input/output is via port 1 on the dracblade.
9) Use a sandisk 1Gb sd card formatted with fat16 (we know other brands work with fat32 using hairmnstrs code)
10) Note just to me - Juergen's sd card has the label upside down.
11) Put A.DSK on the sd card from page 1 of this thread. Copy a blank drive onto the sd card and make 7 copies named B.DSK to H.DSK
12) Reboot with Teraterm running
13) Run MP/M
And then it hangs.
Hmm - need some debugging output - to local vga or LCD screen...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 4/19/2010 2:00:11 PM GMT
Do you reset the high address latch (command "H", 0) at boot, I couldn't see it in your code, if not then where the bootloader gets put in RAM is wherever the 374 is pointing at power up/reset from last run which would be why it sometimes works and sometimes doesn't.
I'll look more this evening when I get home.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Yes, the boot code does it by setting the bank to 0 when banking is supported.
The code in hdsk_setup_dma in io.spin then always sets the high latch to 0.
BTW banking works in principle. I can go and assemble the folllowing lines in CP/M using DDTZ:
This switched to bank 1 and then leads to booting CP/M again, because the banked code vanished.
Now if I enter almost the same code again, except changing the LD A,01 to LD A,00, I can switch back to bank 0 without rebooting CP/M, because the same program is in memory and the stack is in the common area. I then can go in each bank switching to the other back and forth.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
EDIT:
To clarify, this XIOS runs on SIMH? If so, I guess the bug is probably in the emulation.
EDIT 2:
Answered before I finished asking... see below.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Post Edited (hairymnstr) : 4/19/2010 5:57:15 PM GMT
It _should_ work, because it works under SIMH. If you try the A.DSK instead of the i.dsk by modifying Dr_A's "mpm" file with the setup for SIMH, you can go to drive I: and run MPM from there. Afterwards you don't have any diskette drive, but just the hard disk drive, so it's working as expected.
The bug in my code has to be triggered inside MP/M, probably not inside the XIOS.
What I wanted to try is to add some debug output to each XIOS function, so I can see what gets called and what is the last action before it hangs.
Edit: What sometimes works a little different is loading MPM.COM into DDTZ and running it from there, i.e. DDTZ MPM.COM and G. Then I get an Bdos Err On A: Bad Sector. Bdos Function: 15 File: $0$.SUP and an 0A> prompt. Entering DIR doesn't find DIR.PRL, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/19/2010 6:14:24 PM GMT
Just as a minor bug report, if you comment out #define HAVE_LCD io.spin causes errors on compilation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Fixed in 0.9.13.
I would love to know what causes the Chopper game to hang with the TRS80 emulation, because that's most probably the same bug that MP/M hits - or at least it's a definite bug in qz80.
It has to be an 8080/8085 opcode, because MP/M is not using Z80 opcodes at all. I should actually try to run it all with q85.spin, adding the banking code in there, too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/19/2010 7:17:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
When I was working on the original zicog code there were some bugs that were hard to find, and heater had left some code that printed out half the registers. I modified it and added all the registers. Then used the 'single stepping' flag and ran the code till it crashed. There simply was no other way to find some bugs, especially ones that happen some time after a program starts. Is there a way to add this code to the qZ80 and then just set it running, printing out the registers for every instruction? Can this be done in spin or does it need translating to pasm?
PRI print_regs 'Print the Z80 registers RegString(string("AF =")) HexOutput(af_reg) RegString(string(" BC =")) HexOutput(bc_reg) RegString(string(" DE =")) HexOutput(de_reg) RegString(string(" HL =")) HexOutput(hl_reg) RegString(string(" SP =")) HexOutput(sp_reg) RegString(string(" PC =")) HexOutput(pc_reg) RegString(string(13,10)) ' new line for alternate register RegString(string("AF'=")) HexOutput(af_reg_alt) RegString(string(" BC'=")) HexOutput(bc_reg_alt) RegString(string(" DE'=")) HexOutput(de_reg_alt) RegString(string(" HL'=")) HexOutput(hl_reg_alt) RegString(string(" IX =")) HexOutput(ix_reg) RegString(string(" IY =")) HexOutput(iy_reg) RegString(string(13,10))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
There is an i/o command "break" that does the same as in ZiCog. It was originally executed when a HALT command was hit, but with interrupt code enabled HALT has to do what it is supposed to do. I can still execute break at some point in qz80, though.
I had a bug in the counterpart of the break in io.spin that is fixed now. I already tried what you suggested. Unfortunately tracing the MP/M code with real time interrupts (50 per second) is impossible, since it does nothing but go to the interrupt routine and overflow the stack with return addresses this way. This is to be expected, because tracing is too slow to handle real time events. I would have to create the interrupts at a much lower rate, or ideally bound to a rate that depends on the traced code's execution speed, i.e. the cycle count of the Z80.
I think I can try with a rate of 1 per second or 1 every couple of seconds and try tracing again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
The bug was in the code that did read the interrupt request. I used t1 there while I should have used tmp, which is what do_interrupt tests for the type of interrupt and vector. DUH!
I think I have to do something to the *.PRL files to make them accessible by everyone. If you enter "user 1" you are booby-trapped now, because there is no executable command. I'll try to "stat *.PRL $sys" or similar to set the system flag on the PRL files. Does anyone know if this should make them accessible for everyone? Edit: Yes, it looks that is required, so you should do it on the A.DSK I supplied.
I lowered the interrupt rate to 20 ticks / second to not waste too much time in the interrupt handler. If you want to try with 50 again (it worked), you have to run gensys and change the setting and also edit mpmxios.mac and set the "ticks equ 20" there.
I also limited the number of hard disks to 4 to save some shared memory. It doesn't help too much for user 0. In MBASIC you have only 19KB free and Wordstar has not enough memory to do anything. If you want to have all 8 hard disks again, edit MPMD.LIB and change the "nhdisks equ 4" line. Afterwards you "DO SYSMPM" to build a new MP/M.
Finally you should be able to include the 8085 core instead of Z80 now. I have to try it again - must disable the Z80 in gensys first, because otherwise the MP/M dispatcher is trying to save the Z80 alternate register set which doesn't work on the 8085. There's a "#define CPU_8085" in cpm.spin which you can enable instead of the "#define CPU_Z80".
Edit: Building MP/M (DO SYSMPM) is possible only with the Z80 core, because the SUB-file runs ddtz.
Here is a helpful link to a CP/M and MP/M handbook PDF.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/20/2010 8:28:28 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.