Wow! I went away on the weekend to take my son to a cub scout camp out and now I log back in and you have the emulator running with keyboard support. Awesome!
I hope you're enjoying some of the old games. I'm glad I was able to dig them out.
Do the other games (Chopper and the Robot game) work now?
Robert
Post Edited (RobotWorkshop) : 3/29/2010 8:49:38 PM GMT
I was just trying to knock up another variation of the DracBlade, with the EEPROM and KBD sharing pin ( after boot up) and the VGA on P23 -26. But my trusty old Weller TCP has just got an OC element. 20 years old, I will have to go and mourn its passing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I've got an ancient Weller TCP with transformer in the stand, it's a wonderful thing and quite possibly older than I am. I've had to change the element twice and the thermostat twice but it's still going. Well worth replacing the element if you can, much cheaper than a comparable replacement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I was just trying to knock up another variation of the DracBlade, with the EEPROM and KBD sharing pin ( after boot up) and the VGA on P23 -26. But my trusty old Weller TCP has just got an OC element. 20 years old, I will have to go and mourn its passing.
I'm using the DracBlade. You just need one pin for TV and can use one of 16-19 of the VGA output with the existing resistors. You'll also need 1 pin for sound output. The pins are all declared in trs80.spin in the #ifdef DracBlade section.
@RobotWorkshop: Chopper: no, it just hangs after displaying the first column of blockgraphics scrolling in from the right side.
Also Bomb Squad hangs - at the Game Over screen. No reaction on any key.
Despite the exerciser giving me 100% ok for the opcodes, there is a bug lurking somewhere.
It would be good to know what kind of opcodes you used in the scroll functions, because at least one of them isn't working right.
Hey, guess what kind of soldering iron I have here? Weller TCP [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
This time I wrote a TRS80 specific version of the keyboard driver using the standard object as the base. It directly manipulates a 64 bit map which corresponds to the TRS80 64 key keyboard, so there is no clumsy double table lookup and lookdown anymore. I may have some wrong keys in there, because I don't have a US keyboard. Also some keys seem to be missing, i.e. generate no output while they should or at least could. I should somehow print the scan codes that are mapped to INVALID and still are coming from my keyboard.
If you want to test keys and their mapping, you best select the empty entry in the file list to go to BASIC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
RobotWorkshop said...
I e-mailed a copy of the source which may help. After looking over the code I did use a few odd instructions (none of the undocumented ones)
I looked at the code, especially at the region where you print the "G a m e o v e r" on the screen, as this is where it hangs. I just can't see any critical opcode in this path. Since the TRS80/Z80 is actually stopped as if it was in a tight loop with no breakout, I first thought it might be the LDIR/LDDR opcodes, because these are the only ones that have tight loops in LMM.
BTW Robotron hangs right from the start, shows only a blank screen, so one of the very first actions of it has to trigger the bug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I can't wait until the parts come in to build up the DracBlade board. It will be nice to have the hardware to help test and try out some of the old games again.
Now that the DJNZ instruction is fixed does the ROBOTRON game work or does that still hang? What about the CLOCK80 program?
I've attached the source for CLOCK80 which may help if that isn't working. It uses an ISR to keep track of the time.
If the robot game still hangs I'll see if I can find the source for that to help with troubleshooting.
Wow, this brings back memories of middle school and TRS-80 models I & III and TRS-DOS!!! One thing that will make things easy is that the TRS80 did not have sound, thought there was a peripheral that could be hooked up to , i think, the printer port that could generate tones. Impressive project!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
Invent-O-Doc said...
Wow, this brings back memories of middle school and TRS-80 models I & III and TRS-DOS!!! One thing that will make things easy is that the TRS80 did not have sound, thought there was a peripheral that could be hooked up to , i think, the printer port that could generate tones. Impressive project!
It was the cassette port, and this is working in the emulation, too. Otherwise games would be half as funny to play [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Actually the sound effects on the TRS-80 were pretty good. At first there wasn't any sound in the programs and some of the early games relied in sitting an AM radio next to the computer to hear the system and depending upon what the code was doing (tight loops, etc) you could actually hear different sounds. Later on people discovered how to use the cassette interface to generate sounds and this was the standard method that just about all the games used. Some of the effects were outstanding (considering it was never meant for that) and a few games even generated digitized speech through the cassette port. All you needed was an amplified speaker plugged into the cassette cable.
Later on there was the Orchestra-80, etc for even better Music but most people never had that option. At one point Radio Shack had an SC-01 based speech synthesizer for speech and a VoxBox for speech recognition. I have one of each still packed away somewhere at my parents house....
The TRS-80 really was a great machine and a pleasure to write programs for. What it lacked in Hi-Res graphics was made up in other areas and it had several mature and stable Disk Operating systems that were ahead of many other systems out at the time. One of the best was Multidos (written by Vernon Hester) and he wrote some amazing add-ons and code to make the system fly.
And fixed another bug - or actually two since the last version (the coffee is working [noparse]:)[/noparse]
* ADD16, i.e. ADD HL,rr and ADD IX/IY,rr were setting the carry flag wrong
* ADC16 and SBC16 could leave H with a value > $FF, which is impossible and lead to Bable Terror's garbled graphics
AFAICT all games are working now. Have to test them again, but that's easy with the file menu selection.
Edit: No, Robotron still only displays a blank screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Unfortunately the source for Robotron doesn't appear to be as intact as the code for the other programs. I found some fragments and some show the startup code for it. I'm going to see if I can find all the pieces. If there is enough interest I may even finish it and add the last few bits to the Time Pilot code as well.
CLEARS LD HL,3C00H
LD DE,3C01H
LD BC,3FFH
LD (HL),80H
LDIR
RET
CLRBUF LD HL,SCREEN
LD DE,SCREEN+1
LD BC,1763
LD (HL),80H
LDIR
RET
MOVBUF LD B,16
LD HL,SCREEN+262
LD DE,3C00H
MOVSC PUSH BC
LD BC,64
LDIR
PUSH DE
LD DE,20
ADD HL,DE
POP DE
POP BC
DJNZ MOVSC
RET
SOUND PUSH BC
LD B,H
LD A,2
OUT (0FFH),A
DJNZ $
LD B,E
XOR A
OUT (0FFH),A
DJNZ $
LD B,L
INC A
OUT (0FFH),A
DJNZ $
POP BC
DEC BC
LD A,B
OR C
JR NZ,SOUND
XOR A
OUT (0FFH),A
RET
NEW2L XOR A
LD (MANFLG),A
LD (MANPRF),A
LD (LEVEL),A
LD (FIRDIR),A
LD (FIRE),A
LD (SHTCNT),A
LD (BONCNT),A
LD (WARP),A
LD (RUN),A
LD (SMART),A
LD (SHIELD),A
LD A,3CH
LD (NOD1),A
LD A,28
LD (MANX),A
LD A,20
LD (MANY),A
LD A,95
LD (LANX),A
LD A,56
LD (LANY),A
RET
START DI
LD SP,5300H
CALL CLEARS
CALL LOADFL
LD A,R
LD (SEED),A
LD A,'a'
LD (3C00H),A
LD A,(3C00H)
CP 'a'
JR Z,OKL
LD HL,0
LD (PRSTR),HL
OKL CALL CLEARS
CALL CLRBUF
LD HL,BY
LD DE,SCREEN+1110
CALL PRSTR
XOR A
LD DE,1A12H
LPFIX PUSH AF
PUSH DE
LD IX,LETTER
LD HL,ROBMSG
PUSH DE
LD E,A
LD D,0
ADD HL,DE
LD A,(HL)
CALL FIND
POP DE
CALL PRTCHR
CALL MOVBUF
LD BC,1000H
CALL 60H
POP DE
LD A,6
ADD A,E
LD E,A
POP AF
INC A
CP 8
JR NZ,LPFIX
LD BC,0
CALL 60H
CALL HIGHBD
LD BC,0
CALL 60H
LD A,3
LD (MEN),A
RESTRT LD B,48
RENEWM CALL INITM2
CALL NEW2L
CALL CLRSHT
CALL INITLN
CALL INITBN
ULOOP CALL CLRBUF
CALL BORDER
CALL DISCAP
CALL PRTMON
CALL PRTMAN
CALL PRTBON
CALL SCORES
CALL MOVBUF
LD HL,RDYMSG
LD DE,15766
CALL PRSTR
ULP CALL 2BH
LD C,A
IN A,(0)
CPL
OR C
JR Z,ULP
LOOP CALL CLRBUF
CALL PASBRK
CALL KEYBRD
CALL BORDER
CALL DISCAP
CALL SHOOT
CALL CRESHT
CALL COINCS
CALL DISHOT
CALL MOVEM
CALL DEADM
CALL PRTMON
CALL DEADP
CALL PRTMAN
CALL COINCB
CALL PRTBON
CALL MONEXP
CALL SCORES
CALL MOVBUF
JR LOOP
VECTOR LD (ADRS+1),HL
LD A,(MASTER+1)
OR A
RET Z
LD B,A
LOPVEC PUSH BC
ADRS CALL 0000H
POP BC
DJNZ LOPVEC
RET
......
FIND2 LD D,0
RLCA
LD E,A
ADD IX,DE
LD E,(IX)
LD D,(IX+1)
RET
FIND LD D,0
RLCA
LD E,A
ADD IX,DE
LD E,(IX)
LD D,(IX+1)
PUSH DE
POP IX
RET
Post Edited (RobotWorkshop) : 3/30/2010 6:53:25 PM GMT
RobotWorkshop said...
Unfortunately the source for Robotron doesn't appear to be as intact as the code for the other programs. I found some fragments and some show the startup code for it. I'm going to see if I can find all the pieces. If there is enough interest I may even finish it and add the last few bits to the Time Pilot code as well.
Finishing: Wouldn't it be fun if you got famous for writing cool games for 30 years old hardware?
It looks like it could be the LOADFL subroutine then, which isn't in the code snippet. You mentioned loading hiscores from disk, perhaps it isn't happy with the DOS BASIC vectors all doing just RET and the actual DOS entry points being not there...
Edit: Yup, that was it. I patched the 2nd CALL after the LD SP,5300h with 3 NOPs and now the game starts. Err.. until you entered a name into the high score table, then it crashes - probably calling non-existing DOS code again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
That section of the code was a separate include file and is intact. There is also some of the other routines mixed in. I should have had comments in there but as I recall I was running out of memory and had to break up the code in separate source files and remove comments to get it to assemble on the TRS-80. Now with cross assemblers and gobs of memory on PC's it would be much easier to go back and tidy up some of the code. This game had some unfinished issues. Sometimes when it starts an enemy creature would be too close to you and you would lose a turn right from the start. I needed to add some more checks to re-arrange the start location of the enemy's to ensure that wouldn't happen. There were also large letters you were supposed to be able to pick up to spell BONUS for extra points and other items to pickup. I had lots of games on the drawing board back then and somewhere have all my notes and TRS-80 screen worksheets with some pretty slick graphics for the system. I'll have to see if I can find them.
Here is disk load routines for Robotron:
LOADFL LD HL,HIGHSC
LD DE,DCB
LD B,0
CALL 4424H
JR NZ,NOLOAD
LD DE,DCB
CALL 4436H
JR NZ,CLRHI
NOLOAD LD DE,DCB
JP 4428H
SAVEHI LD HL,HIGHSC
LD DE,DCB
LD B,0
CALL 4420H
JR NZ,NOLOAD
CALL 4439H
JR NOLOAD
CLRHI LD B,10
LD DE,HIGHSC
LOOPCH LD HL,INITM
CALL PRSTR
LD (DE),A
INC DE
INC HL
CALL PRSTR
LD (DE),A
INC DE
INC HL
DJNZ LOOPCH
RET
HIGHB2 CALL CLEARS
CALL CLRBUF
CALL ENTPFT
JR HIHDSP
HIGHBD CALL CLEARS
CALL CLRBUF
HIHDSP XOR A
LD DE,0C12H
LP4 PUSH AF
PUSH DE
LD IX,LETTER
LD HL,ROBMSG
PUSH DE
LD E,A
LD D,0
ADD HL,DE
LD A,(HL)
CALL FIND
POP DE
CALL PRTCHR
POP DE
LD A,6
ADD A,E
LD E,A
POP AF
INC A
CP 8
JR NZ,LP4
XOR A
LD DE,1715H
LP5 PUSH AF
PUSH DE
LD IX,LETTER
LD HL,TOP
PUSH DE
LD E,A
LD D,0
ADD HL,DE
LD A,(HL)
CALL FIND
POP DE
CALL PRTCHR
POP DE
LD A,6
ADD A,E
LD E,A
POP AF
INC A
CP 3
JR NZ,LP5
LD A,6
ADD A,E
LD E,A
XOR A
LP6 PUSH AF
PUSH DE
LD IX,LETTER
LD HL,TEN
PUSH DE
LD E,A
LD D,0
ADD HL,DE
LD A,(HL)
CALL FIND
POP DE
CALL PRTCHR
POP DE
LD A,6
ADD A,E
LD E,A
POP AF
INC A
CP 3
JR NZ,LP6
CALL BORD
CALL MOVBUF
XOR A
LP8 PUSH AF
LD IX,TPTN
CALL FIND2
EX DE,HL
POP AF
PUSH AF
LD IX,HIHADR
CALL FIND2
CALL PRSTR
POP AF
PUSH AF
PUSH DE
LD IX,HIGHTB
CALL FIND2
LD HL,7
ADD HL,DE
POP DE
CALL PRSTR
INC DE
POP AF
PUSH AF
PUSH DE
LD IX,HIGHTB
CALL FIND2
EX DE,HL
POP DE
CALL PRTS
POP AF
INC A
CP 10
JR NZ,LP8
RET
BORD LD HL,SCREEN+1020
LD B,60
BORD1 LD (HL),143
INC HL
DJNZ BORD1
LD HL,SCREEN+1522
LD B,64
BORD2 LD (HL),143
INC HL
DJNZ BORD2
LD IX,SCREEN+1018
LD DE,84
LD B,6
BORD3 LD (IX),191
LD (IX+1),191
LD (IX+31),191
LD (IX+32),191
LD (IX+62),191
LD (IX+63),191
ADD IX,DE
DJNZ BORD3
RET
ENTPFT LD HL,ENTMAN
LD DE,SCREEN+940
JP PRSTR
ENTNAM XOR A
ENTLP PUSH AF
LD IX,HIGHTB
CALL FIND2
LD HL,SCORE
LD B,6
CMP LD A,(DE)
SUB (HL)
JR C,HIGR
JR NZ,NXTNUM
INC DE
INC HL
DJNZ CMP
NXTNUM POP AF
INC A
CP 10
JR NZ,,(IY+1)
LD A,(IY+4)
LD (IY+1),A
LD (IY+4),C
LD C,(IY+2)
LD A,(IY+5)
LD (IY+2),A
LD (IY+5),C
CONTSR INC IY
INC IY
INC IY
DJNZ SORTL1
POP IY
POP BC
DJNZ SORTLP
LD B,6
LD IY,TABLE
BOOMLP PUSH BC
LD A,(IY+2)
OR A
JR Z,NTBOOM
LD (IY+2),0
CALL CLRBUF
CALL PRTCON
LD DE,BUFFER
CALL PRTS2
CALL PRTMAN
PUSH IY
CALL DISBMB
PUSH HL
CALL HIGHB2
POP HL
POP DE
LD A,16
CALL INPUT
JP SAVEHI
It is fantastic to see all the progress you've made on the emulator!
Robert
Post Edited (RobotWorkshop) : 3/30/2010 6:52:19 PM GMT
Once everything is running well with the emulator I suppose one of the next items that would help is to try and find a decent z-80 cross assembler that could be used to generate some of the cmd files for the TRS-80 emulator. With that I am sure I could re-construct the source for the robotron game. I also found some source that I had for other games (one was a maze game) and several other routines. I also found the code for a very early game I wrote. It worked most of the time but I had an elusive bug in a fill routine that would make it crash horribly once in a while. Never fixed that and probably could have used a second set of eyes on that code. I know I had many other things written but I can't find them anywhere.
RobotWorkshop said...
Once everything is running well with the emulator I suppose one of the next items that would help is to try and find a decent z-80 cross assembler that could be used to generate some of the cmd files for the TRS-80 emulator. With that I am sure I could re-construct the source for the robotron game. I also found some source that I had for other games (one was a maze game) and several other routines. I also found the code for a very early game I wrote. It worked most of the time but I had an elusive bug in a fill routine that would make it crash horribly once in a while. Never fixed that and probably could have used a second set of eyes on that code. I know I had many other things written but I can't find them anywhere.
Robert
If you don't need macros, you could use mine. It's included with the yaz80 source and written in lex/yacc.
I used it to write some test programs when I had just the Propeller's memory on my PropRPM board.
If memory wasn't so tight as it is now (7420 longs of 8192), I would actually try to emulate the FDC 1791 and we could run NEWDOS/80 - the other DOSes never worked for me, they probably wanted to see different bits from the controller.
BTW if you use {code}{/code} tags - with square brackets, I just used curly brackets to make the tags show - your code will be readable a little better. I don't get why Parallax didn't use a fixed font for the code in the CSS, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
After a lot of bug hunting and trial + error it came out the the SD card low level driver absolutely want's to run on the first free cog, i.e. cog #1 as long as you also run the Spin interpreter. If it runs on cog #2 or higher, it fails to correctly load from my SD cards and causes all kinds of strange effects. This happens in a minimal test program using just two objects. I don't know if this is so only on the DracBlade. I can only guess that the distance between Prop and SD card might play a role, but I have no explanation for the cog dependency.
Are you willing to share the code that is the minimal duplication of this problem? Clearly this is a problem that others may
experience and we should resolve it as soon as possible. Other people have reported things like this, but so far we have
been unable to reproduce it on any of our environments.
Are you willing to share the code that is the minimal duplication of this problem? Clearly this is a problem that others may
experience and we should resolve it as soon as possible. Other people have reported things like this, but so far we have
been unable to reproduce it on any of our environments.
Please help us understand why this is happening.
-tom
See attached files. This test requires the DracBlade, because I use its extended memory manager. You might also use a RamBlade or TriBlade, as there are compatible XMM managers.
To see the effect, swap the initialization of xmm and sd. Or perhaps insert another object before sd. In either case the copy to RAM loop will hang. Other things don't happen in this test program, but you may have read my various comments on what all seemed broken while I was searching for the problem cause.
What is happening is beyond my scope. I can see no reason why the number of previous cogs should make a difference. They are all equal and have the same length of the schedule window, just at another point in time.
Good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll said...
If you don't need macros, you could use mine. It's included with the yaz80 source and written in lex/yacc.
I used it to write some test programs when I had just the Propeller's memory on my PropRPM board.
If memory wasn't so tight as it is now (7420 longs of 8192), I would actually try to emulate the FDC 1791 and we could run NEWDOS/80 - the other DOSes never worked for me, they probably wanted to see different bits from the controller.
BTW if you use {code}{/code} tags - with square brackets, I just used curly brackets to make the tags show - your code will be readable a little better. I don't get why Parallax didn't use a fixed font for the code in the CSS, though.
I never used macro's in my code so it was fairly portable across assemblers. Once I get the DracBlade built I can try it out.
With emulating the Model I it would probably also need a 1771 as well since they usually had both when th double density board was installed. It could write a sector mark that the 1791 couldn't and some of the DOS's expected that feature since it was sometimes used to mark the directory of the disk. (Although I have probably forgotten more than I remember about it)
Adding the {code} tags helps a lot. I went back and cleaned up the previous posts and add them.
RobotWorkshop said...
I never used macro's in my code so it was fairly portable across assemblers. Once I get the DracBlade built I can try it out.
You can try it before you have the DracBlade. I may add an option to create a CMD file from the output. Currently it supports the Colour Genie and VZ200 cassette formats as an alternative to raw binary. You would need bison and flex to compile it, or I can try and create a binary for you. Are you running an OS from Redmond, or something real?
RobotWorkshop said...
With emulating the Model I it would probably also need a 1771 as well since they usually had both when th double density board was installed. It could write a sector mark that the 1791 couldn't and some of the DOS's expected that feature since it was sometimes used to mark the directory of the disk. (Although I have probably forgotten more than I remember about it)
I've written several emulations of this FDC, the first being a mere translation of operations to the PC's NEC765. It allowed me to read some real 5 1/4" disks and save them as images.
I don't know what the issue with other DOSes but NEWDOS/80 is. It may be as simple as motor and head control, or they expect a minor difference in the status codes.
Directory sectors are marked with the DAM = deleted address mark. This must be supported and I had that.. What is tricky is the disks with different densities: single density for track 0 and double density for the rest was a commonly used format, I even believe the default for NEWDOS/80.
If I find a way to use the reusable portions of hub RAM for the iobuffer (1KB) and the video RAM (also 1KB) I could give it a try. I have C source here that I only had to translate to PASM.
Edit: Hmm... no, after looking at the source I think this is too much for the little Propeller. It would require a) an image file support like DMK b) the WD179x emulation, which alone probably won't fit in a cog and c) the TRS80 hardware emulation: motor and head control and interrupt generation. So I won't try it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I found the reference I was thinking about regarding the 1771. It was really an issue with TRSDOS:
said...
TRS-80 operating systems differentiate directory sectors from ordinary data sectors by giving them different data address marks. Unfortunately, Model I TRSDOS uses 0xFA on directory sectors, which a WD179x cannot write and cannot distinguish from the 0xFB used on data sectors. Other Model I operating systems (such as LDOS) typically write 0xF8 on directory sectors but accept either 0xFA or 0xF8 when reading them, allowing them to read TRSDOS disks. Compatibility problems remain when attempting to use Model I TRSDOS disks on a Model III or 4, and when attempting to use LDOS disks with Model I TRSDOS.
RobotWorkshop said...
I found the reference I was thinking about regarding the 1771. It was really an issue with TRSDOS:
said...
TRS-80 operating systems differentiate directory sectors from ordinary data sectors by giving them different data address marks. Unfortunately, Model I TRSDOS uses 0xFA on directory sectors, which a WD179x cannot write and cannot distinguish from the 0xFB used on data sectors. Other Model I operating systems (such as LDOS) typically write 0xF8 on directory sectors but accept either 0xFA or 0xF8 when reading them, allowing them to read TRSDOS disks. Compatibility problems remain when attempting to use Model I TRSDOS disks on a Model III or 4, and when attempting to use LDOS disks with Model I TRSDOS.
Ahh.. this is the reason! It's true, the 179x doesn't differentiate the kind of deleted address mark and can thus write just one type.
The DMK image format supports raw tracks and can thus handle all address marks between f8 and fb.
It defaults to (or really only supports) f8 for deleted sectors. At least this is what my DMK image handler uses when writing a sector to the track image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
This test requires the DracBlade, because I use its extended memory manager.
Thanks!
I only have a demo board, so I'll have to try to replicate the problem there.
Of course that will require such substantial changes that it's unclear if I'll
actually have any chance of success.
Re robotworkshop "Once everything is running well with the emulator I suppose one of the next items that would help is to try and find a decent z-80 cross assembler"
I use a number of compilers. An automated compile on the SIMH for .asm files. A similar process for .mac files. Also a program called RASM which the N8VEM group uses to recompile the source code. They all compile in a second or two.
Every compiler uses different syntax. Some put . before the equ commands some don't. Some default to compiling at 100H and some at 0H.
Could you post an example of code and we could see which existing compiler it is closest to.
Re "I only have a demo board"
There is nothing that special about the dracblade - really it is just a HC138 and three latches and a ram chip. You might be able to put that on a little mezzanine board above the demo board. Or get a dracblade board for $10 including shipping.
I use z80asm from the Ubuntu repository generally because it's easy to get hold of and I know the syntax now but I can't say it's the best, has a nasty habit of compiling lines with garbage on the end so when I'm not paying attention and write "xor a,c" for example, it compiles perfectly and then doesn't do what I was expecting. (i.e. xor a instead of xor c)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Dr_Acula said...
Re robotworkshop "Once everything is running well with the emulator I suppose one of the next items that would help is to try and find a decent z-80 cross assembler"
I use a number of compilers. An automated compile on the SIMH for .asm files. A similar process for .mac files. Also a program called RASM which the N8VEM group uses to recompile the source code. They all compile in a second or two.
Every compiler uses different syntax. Some put . before the equ commands some don't. Some default to compiling at 100H and some at 0H.
Could you post an example of code and we could see which existing compiler it is closest to.
In one of my previous posts there is a clock.zip file as an attachment. It has the full source for the clock80 program. It would be a good test case to see if that can compile and then generate a cmd file. I can gather up some of the other code too.
@RW I'll give that one a try. Should be rather easy to add *.CMD support.
Okay, there is one problem that is easy to fix: The single quote generally defines a character and can be used in places where a byte would be expected. The DEFM instruction however expects a string, or a list of strings and bytes, and the strings have to be enclosed in double quotes. This requirement is needed, because otherwise the parser cannot handle this.
You can write
DEFM "Hello world!",13,10,0
Or even
DEFM 'H','e','l','l','o'," world!",0dh,0ah,0
But not
DEFM 'Hello'," world!",13,10
The latter would use just the 'H' and ignore the rest of the string.
I could try to make an exception from the rule that anything 'x' is a byte. I could instruct the lexer to enter a special state after it found DEFM where ' was a valid string delimiter, but I think this is not worth the hassle.
Attached is the listing of az80 -l clock.asm and a CMD file created from it. I hope the comment record works. It should work with my loader.
Source is attached as well. You need bison and flex besides GCC to compile it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
hairymnstr said...
I use z80asm from the Ubuntu repository generally because it's easy to get hold of and I know the syntax now but I can't say it's the best, has a nasty habit of compiling lines with garbage on the end so when I'm not paying attention and write "xor a,c" for example, it compiles perfectly and then doesn't do what I was expecting. (i.e. xor a instead of xor c)
My az80 is very picky and wouldn't let that slip through. The only problem is that sometimes the exact location of an error is hard to decipher from its output. There can be errors following the first error which might confuse you. But usually the first error is the one to fix to get rid of the others too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
I hope you're enjoying some of the old games. I'm glad I was able to dig them out.
Do the other games (Chopper and the Robot game) work now?
Robert
Post Edited (RobotWorkshop) : 3/29/2010 8:49:38 PM GMT
Which board are you using for the TRS80 work ?
I was just trying to knock up another variation of the DracBlade, with the EEPROM and KBD sharing pin ( after boot up) and the VGA on P23 -26. But my trusty old Weller TCP has just got an OC element. 20 years old, I will have to go and mourn its passing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I'm using the DracBlade. You just need one pin for TV and can use one of 16-19 of the VGA output with the existing resistors. You'll also need 1 pin for sound output. The pins are all declared in trs80.spin in the #ifdef DracBlade section.
@RobotWorkshop: Chopper: no, it just hangs after displaying the first column of blockgraphics scrolling in from the right side.
Also Bomb Squad hangs - at the Game Over screen. No reaction on any key.
Despite the exerciser giving me 100% ok for the opcodes, there is a bug lurking somewhere.
It would be good to know what kind of opcodes you used in the scroll functions, because at least one of them isn't working right.
Hey, guess what kind of soldering iron I have here? Weller TCP [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/30/2010 2:44:07 AM GMT
Some that jumped out are:
SLA A
SRL E
SLA C
IN A,(0) ;to read the joystick
RET Z
CPL
RLCA
RLA
LD A,(IX+1)
LD (IX+2),0
DEC (IX)
LD C,(IY+3)
Robert
This time I wrote a TRS80 specific version of the keyboard driver using the standard object as the base. It directly manipulates a 64 bit map which corresponds to the TRS80 64 key keyboard, so there is no clumsy double table lookup and lookdown anymore. I may have some wrong keys in there, because I don't have a US keyboard. Also some keys seem to be missing, i.e. generate no output while they should or at least could. I should somehow print the scan codes that are mapped to INVALID and still are coming from my keyboard.
If you want to test keys and their mapping, you best select the empty entry in the file list to go to BASIC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/30/2010 9:31:01 AM GMT
I looked at the code, especially at the region where you print the "G a m e o v e r" on the screen, as this is where it hangs. I just can't see any critical opcode in this path. Since the TRS80/Z80 is actually stopped as if it was in a tight loop with no breakout, I first thought it might be the LDIR/LDDR opcodes, because these are the only ones that have tight loops in LMM.
BTW Robotron hangs right from the start, shows only a blank screen, so one of the very first actions of it has to trigger the bug.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Now that the DJNZ instruction is fixed does the ROBOTRON game work or does that still hang? What about the CLOCK80 program?
I've attached the source for CLOCK80 which may help if that isn't working. It uses an ISR to keep track of the time.
If the robot game still hangs I'll see if I can find the source for that to help with troubleshooting.
Robert
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
It was the cassette port, and this is working in the emulation, too. Otherwise games would be half as funny to play [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Actually the sound effects on the TRS-80 were pretty good. At first there wasn't any sound in the programs and some of the early games relied in sitting an AM radio next to the computer to hear the system and depending upon what the code was doing (tight loops, etc) you could actually hear different sounds. Later on people discovered how to use the cassette interface to generate sounds and this was the standard method that just about all the games used. Some of the effects were outstanding (considering it was never meant for that) and a few games even generated digitized speech through the cassette port. All you needed was an amplified speaker plugged into the cassette cable.
Later on there was the Orchestra-80, etc for even better Music but most people never had that option. At one point Radio Shack had an SC-01 based speech synthesizer for speech and a VoxBox for speech recognition. I have one of each still packed away somewhere at my parents house....
The TRS-80 really was a great machine and a pleasure to write programs for. What it lacked in Hi-Res graphics was made up in other areas and it had several mature and stable Disk Operating systems that were ahead of many other systems out at the time. One of the best was Multidos (written by Vernon Hester) and he wrote some amazing add-ons and code to make the system fly.
Robert
* ADD16, i.e. ADD HL,rr and ADD IX/IY,rr were setting the carry flag wrong
* ADC16 and SBC16 could leave H with a value > $FF, which is impossible and lead to Bable Terror's garbled graphics
AFAICT all games are working now. Have to test them again, but that's easy with the file menu selection.
Edit: No, Robotron still only displays a blank screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (RobotWorkshop) : 3/30/2010 6:53:25 PM GMT
Finishing: Wouldn't it be fun if you got famous for writing cool games for 30 years old hardware?
It looks like it could be the LOADFL subroutine then, which isn't in the code snippet. You mentioned loading hiscores from disk, perhaps it isn't happy with the DOS BASIC vectors all doing just RET and the actual DOS entry points being not there...
Edit: Yup, that was it. I patched the 2nd CALL after the LD SP,5300h with 3 NOPs and now the game starts. Err.. until you entered a name into the high score table, then it crashes - probably calling non-existing DOS code again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/30/2010 3:25:33 PM GMT
Here is disk load routines for Robotron:
It is fantastic to see all the progress you've made on the emulator!
Robert
Post Edited (RobotWorkshop) : 3/30/2010 6:52:19 PM GMT
Robert
If you don't need macros, you could use mine. It's included with the yaz80 source and written in lex/yacc.
I used it to write some test programs when I had just the Propeller's memory on my PropRPM board.
If memory wasn't so tight as it is now (7420 longs of 8192), I would actually try to emulate the FDC 1791 and we could run NEWDOS/80 - the other DOSes never worked for me, they probably wanted to see different bits from the controller.
BTW if you use {code}{/code} tags - with square brackets, I just used curly brackets to make the tags show - your code will be readable a little better. I don't get why Parallax didn't use a fixed font for the code in the CSS, though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/30/2010 4:16:14 PM GMT
Are you willing to share the code that is the minimal duplication of this problem? Clearly this is a problem that others may
experience and we should resolve it as soon as possible. Other people have reported things like this, but so far we have
been unable to reproduce it on any of our environments.
Please help us understand why this is happening.
-tom
See attached files. This test requires the DracBlade, because I use its extended memory manager. You might also use a RamBlade or TriBlade, as there are compatible XMM managers.
To see the effect, swap the initialization of xmm and sd. Or perhaps insert another object before sd. In either case the copy to RAM loop will hang. Other things don't happen in this test program, but you may have read my various comments on what all seemed broken while I was searching for the problem cause.
What is happening is beyond my scope. I can see no reason why the number of previous cogs should make a difference. They are all equal and have the same length of the schedule window, just at another point in time.
Good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I never used macro's in my code so it was fairly portable across assemblers. Once I get the DracBlade built I can try it out.
With emulating the Model I it would probably also need a 1771 as well since they usually had both when th double density board was installed. It could write a sector mark that the 1791 couldn't and some of the DOS's expected that feature since it was sometimes used to mark the directory of the disk. (Although I have probably forgotten more than I remember about it)
Adding the {code} tags helps a lot. I went back and cleaned up the previous posts and add them.
Robert
You can try it before you have the DracBlade. I may add an option to create a CMD file from the output. Currently it supports the Colour Genie and VZ200 cassette formats as an alternative to raw binary. You would need bison and flex to compile it, or I can try and create a binary for you. Are you running an OS from Redmond, or something real?
I've written several emulations of this FDC, the first being a mere translation of operations to the PC's NEC765. It allowed me to read some real 5 1/4" disks and save them as images.
I don't know what the issue with other DOSes but NEWDOS/80 is. It may be as simple as motor and head control, or they expect a minor difference in the status codes.
Directory sectors are marked with the DAM = deleted address mark. This must be supported and I had that.. What is tricky is the disks with different densities: single density for track 0 and double density for the rest was a commonly used format, I even believe the default for NEWDOS/80.
If I find a way to use the reusable portions of hub RAM for the iobuffer (1KB) and the video RAM (also 1KB) I could give it a try. I have C source here that I only had to translate to PASM.
Edit: Hmm... no, after looking at the source I think this is too much for the little Propeller. It would require a) an image file support like DMK b) the WD179x emulation, which alone probably won't fit in a cog and c) the TRS80 hardware emulation: motor and head control and interrupt generation. So I won't try it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/30/2010 7:26:04 PM GMT
This came from: www.tim-mann.org/trs80/dskspec.html
Robert
Ahh.. this is the reason! It's true, the 179x doesn't differentiate the kind of deleted address mark and can thus write just one type.
The DMK image format supports raw tracks and can thus handle all address marks between f8 and fb.
It defaults to (or really only supports) f8 for deleted sectors. At least this is what my DMK image handler uses when writing a sector to the track image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Thanks!
I only have a demo board, so I'll have to try to replicate the problem there.
Of course that will require such substantial changes that it's unclear if I'll
actually have any chance of success.
I use a number of compilers. An automated compile on the SIMH for .asm files. A similar process for .mac files. Also a program called RASM which the N8VEM group uses to recompile the source code. They all compile in a second or two.
Every compiler uses different syntax. Some put . before the equ commands some don't. Some default to compiling at 100H and some at 0H.
Could you post an example of code and we could see which existing compiler it is closest to.
Re "I only have a demo board"
There is nothing that special about the dracblade - really it is just a HC138 and three latches and a ram chip. You might be able to put that on a little mezzanine board above the demo board. Or get a dracblade board for $10 including shipping.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/30/2010 10:45:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
In one of my previous posts there is a clock.zip file as an attachment. It has the full source for the clock80 program. It would be a good test case to see if that can compile and then generate a cmd file. I can gather up some of the other code too.
Robert
Okay, there is one problem that is easy to fix: The single quote generally defines a character and can be used in places where a byte would be expected. The DEFM instruction however expects a string, or a list of strings and bytes, and the strings have to be enclosed in double quotes. This requirement is needed, because otherwise the parser cannot handle this.
You can write
DEFM "Hello world!",13,10,0
Or even
DEFM 'H','e','l','l','o'," world!",0dh,0ah,0
But not
DEFM 'Hello'," world!",13,10
The latter would use just the 'H' and ignore the rest of the string.
I could try to make an exception from the rule that anything 'x' is a byte. I could instruct the lexer to enter a special state after it found DEFM where ' was a valid string delimiter, but I think this is not worth the hassle.
Attached is the listing of az80 -l clock.asm and a CMD file created from it. I hope the comment record works. It should work with my loader.
Source is attached as well. You need bison and flex besides GCC to compile it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/31/2010 1:11:09 PM GMT
My az80 is very picky and wouldn't let that slip through. The only problem is that sometimes the exact location of an error is hard to decipher from its output. There can be errors following the first error which might confuse you. But usually the first error is the one to fix to get rid of the others too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.