Cluso99 said...
BTW You should really use the much improved later fsrw2.6 (see Zicog150)
I'll do that. I just took what was lying around in my ever growing directory tree of propeller projects.
No, wait. I don't use fsrw at all. The DOS/FAT routines are my own written in Spin. I thought you meant another sdspi object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
For the Timepilot programs you need to press a number 0-5 to start the game. Whatever number you press sets the level (time period) to start. The arrow keys will let you move and the space bar fires.
I looked at the old code for the Chopper program and it would load/save hi scores to disk. When it starts it tries to load in a file and calls the OS routines at 4424H, 4436H, 4428H, 4420H, and 4439H. It also calls a ROM routine at 2bH and the clear screen at 01c9H which may need something initialized by the OS. Too bad, that game is complete and plays well. The Robotron also used a high score file. I'll bet that is probably the issue. I can probably patch the binary files to just skip that feature by either filling it with NOP's or adding a RET instruction at the entry point of the subroutine for saving to disk.
What about the BOMBSQD.CMD ? I'd expect that one should run ok as it is and at least show the attract mode. In order to play that you just need the number 1, 2 and arrows to work. The keyboard is memory mapped and it directly read address 3840h which was the location of the arrow keys. It also did an IN on port 0 since that is the address of the Alpha joystick (they interfaced an Atari Joystick) so you could control the game with either one.
I've also attached a clock program I wrote for the TRS-80. It uses Interrupts to keep track of time. The model 1 had 40 per second and the Model 3 had 30. It uses self modifying code to patch itself to run on either system.
Robert
Post Edited (RobotWorkshop) : 3/26/2010 7:09:44 PM GMT
Oops. I overlooked that one. It starts, shows the bomb, white screen and then for a fraction of a second some other screen. Then it seems to hit a HALT instruction, because my serial console dumps the registers in that case. Okay, anyway, I can do more tests once I found the keyboard bug. This is priority one now. [noparse]:)[/noparse]
The exact same files work in the CP/M environment, and they fail in the TRS80, so it has to be one of io.spin or trs80_video.spin or trs80_render.spin that go havoc with something that belongs to the keyboard driver. This narrows it down to a few dozen lines of code...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
That one calls address 0060H (I believe a delay routine) and also address 002BH which scans the Keyboard as I recall.
I ordered some parts to put together a Dracblade but until I can build up the hardware all I can help with is providing some sample programs and go through some of their code to figure out what parts of the underling hardware it relies on.
How are you handling the keyboard? are you keeping an image of the memory map for the keyboard area and just updating it with the make/break key info from the keyboard driver? I'd expect that to work for the ROM code and my old games.
RobotWorkshop said...
I ordered some parts to put together a Dracblade but until I can build up the hardware all I can help with is providing some sample programs and go through some of their code to figure out what parts of the underling hardware it relies on.
Well, if you speak PASM, you could perhaps find my fault in the three mentioned files. I has to be some dumb thing like swapping register and address in a wrbyte/word/long (I had that), a missing # after a jmp or something like that.
RobotWorkshop said...
How are you handling the keyboard? are you keeping an image of the memory map for the keyboard area and just updating it with the make/break key info from the keyboard driver? I'd expect that to work for the ROM code and my old games.
Great work so far!
Robert.
Fortunately the OBEX Keyboard.spin driver already has a bitmap of active keys. All I have done is write an array of 64 bytes that maps a PS/2 keyboard bit to its TRS80 keyboard counterpart. I had to patch Keyboard.spin to set a rendezvous long to inform my I/O handler of key releases, ie. break codes, too, because otherwise it would be impossible to detect them. So the code in my io.spin that is waiting for a Z80 i/o command to handle also inspects this keyboard rendezvous long, and if it is non zero, reads the 64 keyboard bitmap flags and updates the Z80 map (8 bytes). The actual memory read from 3800-38ff is decoded into the 8 address lines and the logical or of the 8 bytes map is returned on the input port.
This all should work, but the keyboard driver itself is doing weird things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Will the emulator allow for self modifying code? One thing
START DI
LD SP,5300H
LD A,'a'
LD (3C00H),A
LD A,(3C00H)
CP 'a'
JR Z,OKL
LD HL,0
LD (PRSTR),HL
.......
; The Print routine took a 0 terminated string at HL and put it at screen address DE. This one was special since it would skip spaces to let the graphics behind show through. If the system didn't support lower case it would overwrite the JR SAME instruction with two NOP's so it would fall through.
PRSTR JR SAME
PRLOP LD A,(HL)
OR A
RET Z
CP 32
JR Z,OK1
CP 'a'
JR C,OKPRT
CP 7BH
JR NC,OKPRT
SUB 20H
OKPRT LD (DE),A
OK1 INC DE
INC HL
JR PRLOP
SAME LD A,(HL)
OR A
RET Z
CP 32
JR Z,OK2
LD (DE),A
OK2 INC DE
INC HL
JR SAME
Post Edited (RobotWorkshop) : 3/30/2010 6:54:33 PM GMT
As I recall the keyboard wasn't fully decoded so that looking at the keyboard memory you'd see the same data in a couple different locations. I think I found the section of code in io.spin where you read the keyboard and map it to an image of the TRS-80 keyboard memory but I'm not fluent enough in PASM yet so I am still trying to make sense of it.
To get random numbers it would use the instruction ld a,r to read the refresh register. That would occur after the initial splash screen. I can see that it is in your emulator but was that part of any of the early code in your test cases?
Robert
Post Edited (RobotWorkshop) : 3/26/2010 9:40:30 PM GMT
I need to get your new LMM code working before you race ahead and I can't catch you!
Latest download above.
I changed Dracblade to DracbladeProp, Now it almost compiles.
Used Yaz80 instead of ZicogLMM
Failing at the start of the this routine
okay := yaz80.start(0, io.command_addr, @videoram_, 0)
I see the syntax has changed from
err := \cpu.start(@reg_base)
(cpu is the same as yaz80) with extra variables. In particular io.command is new and all the port addresses seem to have been moved into "io" instead of in the main program. And that includes the keyboard and I gather the keyboard is not working.
Have you got a CP/M version working with your latest yaz80 code, and if so, does it include the keyboard?
If not, what variables could I send to yaz80.start so it can work with CP/M?
As I recall the keyboard wasn't fully decoded so that looking at the keyboard memory you'd see the same data in a couple different locations. I think I found the section of code in io.spin where you read the keyboard and map it to an image of the TRS-80 keyboard memory but I'm not fluent enough in PASM yet so I am still trying to make sense of it.
It was actually pretty tricky. They used the address lines A0-A7 directly to the keyboard rows and D0-D7 to the columns. So reading 3801 you get the first row, 3802 2nd, 3804, 3808 etc. But you could also read 2 keys at once, or even all keys. 38ff would read all keyboard rows and you could immediately see if any key was pressed. I mimic this by having 8 bytes of keyboard row data and checking the memory address that was accessed for bits 0..7, combining the addressed rows with OR.
Actually I'm not yet sure if I have to invert the logic to AND the inverted addressed rows together...
RobotWorkshop said...
To get random numbers it would use the instruction ld a,r to read the refresh register. That would occur after the initial splash screen. I can see that it is in your emulator but was that part of any of the early code in your test cases?
The R register is implemented for that very reason, yes. Many games used it as pseudo random value. It isn't tested at all by the exerciser code if you meant that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I need to get your new LMM code working before you race ahead and I can't catch you!
Latest download above.
I changed Dracblade to DracbladeProp, Now it almost compiles.
Used Yaz80 instead of ZicogLMM
Failing at the start of the this routine
okay := yaz80.start(0, io.command_addr, @videoram_, 0)
I see the syntax has changed from
err := \cpu.start(@reg_base)
(cpu is the same as yaz80) with extra variables. In particular io.command is new and all the port addresses seem to have been moved into "io" instead of in the main program. And that includes the keyboard and I gather the keyboard is not working.
Have you got a CP/M version working with your latest yaz80 code, and if so, does it include the keyboard?
If not, what variables could I send to yaz80.start so it can work with CP/M?
Hmm.. pasting yaz80 to your environment of io handling etc. is possible, but not easy. I wrote my own version of everything supported so far in io.spin. Actually the unmodified archive should work with a terminal like PST at 115k2. No VGA video yet and the PS/2 keyboard is giving me only 0s and 1s, i.e. ^@ and ^A. I haven't figured that bug yet.
If you want to run yaz80 in your environment, you would specify the address of the io_command variable in your i/o code as 2nd parameter, i.e. @io_command and the other parameters as 0s. Just don't ask me how far you will get with it. The i/o is still compatible to ZiCog, though. I intend to change it. See the other thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I looked at some (sound) PWM code to understand how it's done. It looks like a dedicated cog is necessary to do it, even if all I need is 3 distinct levels of volume. Perhaps anyone can come up with an easier solution? The 3 output levels were 0V, 0.46V and 0.85V in the theoretical range of 0..1V.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I managed to squeeze the video code in one cog now by doing 2 characters for each waitvid, combining the 2x6 bits into one word.
The FDS isn't required anymore, because the info output is now displayed on the TV screen.
I included some CMD files for you to play with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
You don't need a dedicated cog, just a free counter.
With a counter in DUTY mode the FRQx register sets the output pulswith. It's no a normal PWM because the frequency
changes with the pulswith, but for sound it's fine.
Ariba said...
You don't need a dedicated cog, just a free counter.
With a counter in DUTY mode the FRQx register sets the output pulswith. It's no a normal PWM because the frequency
changes with the pulswith, but for sound it's fine.
I don't really undestand if you need the voltages 0, 0.46 and 0.85 or the percentage to 1V, so I calculated both.
Andy
Thank you for the explanation. That is as easy as I expected it to be [noparse]:)[/noparse] The actual voltages would be interesting if you wanted to use my emulator to create TRS80 cassette tapes from within it. Otherwise I guess you would use a resistor voltage divider on the output pin to ensure your audio input doesn't get too high a level.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Didn't the TRS-80 just use one bit to output to tape and the games just put one-bit sound out the
mic plug, which you either plugged into a 276(?)-1008 amp or push the mic monitor switch on the tape deck?
PWM wasn't the method used then, I don't think. But maybe... I'm not sure.
Usually a 50% duty cycle square wave whose frequency was controlled by a countdown loop in ASM.
Except for certain sound effects which were loaded (at least by myself) from the cassette tape!
Got the pac-man game?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
VIRAND said...
Didn't the TRS-80 just use one bit to output to tape and the games just put one-bit sound out the
mic plug, which you either plugged into a 276(?)-1008 amp or push the mic monitor switch on the tape deck?
No, it used two bits, #0 and #1. The levels produced by the external circuitry were
0: 0.46V
1: 0V
2: 0.85V
3: 0V
VIRAND said...
PWM wasn't the method used then, I don't think. But maybe... I'm not sure.
Yeah [noparse]:)[/noparse]
VIRAND said...
Usually a 50% duty cycle square wave whose frequency was controlled by a countdown loop in ASM.
Except for certain sound effects which were loaded (at least by myself) from the cassette tape!
Got the pac-man game?
I think so. I've got several hundred or thousand CMD files and never had the chance to look through all or even many of them.
You know, there once was trs80.org, and I was ambitious to download the internet to my PC anyway...
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Here's a new version, after a nightmare of changing to modern day's SD SPI interface.
font changed to 6x15 to use the full height of the TV screen (64x16 @ 6x15 = 384x240)
changed SD card object to mb_rawb_spi16_rr007.spin (007 is my mod to export SPI_command)
fixed TRS80.ROM and CMD loading (default is GALAXY.CMD, change to your needs)
Changed loader to jump to the program after basic vector initialization by the BASIC ROM
The keyboard is still erratic and so playing the games is still impossible.
Galaxy has a nice attract mode, so you can at least look at something.
The ZIP includes some more games in the CMD subdirectory, as well as the required TRS80.ROM
Sound _might_ be working. I haven't found a definite pin to use on the DracBlade yet.
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.
Have fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm not sure what is wrong with the keyboard - I gather it works with the original keyboard but something changes and it doesn't work?
Re sound, if you are using TV then there are 4 or 5 pins you could use for sound. An onboard audio amp could be a simple 8 pin chip and a few components so might not make the board much bigger.
The "nightmare of changing to the modern sd SPI" is the reason I have not attempted it, but I imagine as cards get bigger it will have to happen for the dracblade code too.
Dr_Acula said...
I'm not sure what is wrong with the keyboard - I gather it works with the original keyboard but something changes and it doesn't work?
The keyboard works in the CP/M environment. I put the translation code for CTRL keys and some specials in i/o and constat/conin also read the PS/2 keyboard now. So the problem is in what I do different in the TRS80 environment. Has to be some trashing of memory out of bounds...
Dr_Acula said...
Re sound, if you are using TV then there are 4 or 5 pins you could use for sound. An onboard audio amp could be a simple 8 pin chip and a few components so might not make the board much bigger.
Hmm. Okay, I use 1pinTV for the black&white output, so there's plenty of pins. I only didn't know that you could use a pin of a VCFG group for other purposes on another cog! That makes it easy.. No, I don't use VGA here because I have no spare monitor at the moment.
Dr_Acula said...
The "nightmare of changing to the modern sd SPI" is the reason I have not attempted it, but I imagine as cards get bigger it will have to happen for the dracblade code too.
The cog dependency bug is very strange.
Yeah, _very_ strange, but then Cluso99 said it was coded to squeeze out all performance one could get. I saw it uses the cog's counters and PSHA registers to read/write bits. No bit banging in software like the Femto code did.
If you can make sure that the SD code is in the first cog, you will have a great win: bigger (cheaper) SD cards, FAT32 support and quicker loading times. I think the hairy monster was wanting to try to embed DracBlade XMM and the SD code in one cog!? If he manages that, it'll be _very_ useful. I think in that case I or someone else should do the same thing for other architectures, namely the RamBlade and perhaps the TriBlade, too. It is nice to have I/O objects using the same semantics for the various hardware and makes the life of us application developers easier [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Here's a little archive of TRS80 code, just in case I get it working real soon now.
It's looking good: sound works like a charme. I used pin 20 of the DracBlade, just after the VGA resistor. Keyboard is working halfways: it reacts on keypresses, but delivers 8 characters instead of 1. Will fix that now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It works - sort of. The keyboard SHIFT function is not yet right, meaning you can't reach all keys. Also, sometimes the recognition of a key is a little flaky, probably because the status is changed after the i/o cog detects a change is under the way. I have to look closer into the original Keyboard object to see how to improve that.
Anyway. You can play games now. I just zapped away a few aliens in Galaxy Invasion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
potatohead said...
The round button thingy in your avatar appears to say Pullmoll... So, what does it mean?
It's a brand. Some kind of candy with sweet herbs. The red thing is the (here) well known package: http://pulmoll.de (note the single L as opposed to my double L)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
And here's the next update. This one now features a file selection dialog after the startup where you can select a *.CMD file from your SD card's root directory.
Have fun! *back to playing time pilot*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
No, wait. I don't use fsrw at all. The DOS/FAT routines are my own written in Spin. I thought you meant another sdspi object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/26/2010 7:04:26 PM GMT
I looked at the old code for the Chopper program and it would load/save hi scores to disk. When it starts it tries to load in a file and calls the OS routines at 4424H, 4436H, 4428H, 4420H, and 4439H. It also calls a ROM routine at 2bH and the clear screen at 01c9H which may need something initialized by the OS. Too bad, that game is complete and plays well. The Robotron also used a high score file. I'll bet that is probably the issue. I can probably patch the binary files to just skip that feature by either filling it with NOP's or adding a RET instruction at the entry point of the subroutine for saving to disk.
What about the BOMBSQD.CMD ? I'd expect that one should run ok as it is and at least show the attract mode. In order to play that you just need the number 1, 2 and arrows to work. The keyboard is memory mapped and it directly read address 3840h which was the location of the arrow keys. It also did an IN on port 0 since that is the address of the Alpha joystick (they interfaced an Atari Joystick) so you could control the game with either one.
I've also attached a clock program I wrote for the TRS-80. It uses Interrupts to keep track of time. The model 1 had 40 per second and the Model 3 had 30. It uses self modifying code to patch itself to run on either system.
Robert
Post Edited (RobotWorkshop) : 3/26/2010 7:09:44 PM GMT
Oops. I overlooked that one. It starts, shows the bomb, white screen and then for a fraction of a second some other screen. Then it seems to hit a HALT instruction, because my serial console dumps the registers in that case. Okay, anyway, I can do more tests once I found the keyboard bug. This is priority one now. [noparse]:)[/noparse]
The exact same files work in the CP/M environment, and they fail in the TRS80, so it has to be one of io.spin or trs80_video.spin or trs80_render.spin that go havoc with something that belongs to the keyboard driver. This narrows it down to a few dozen lines of code...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/26/2010 7:25:31 PM GMT
I ordered some parts to put together a Dracblade but until I can build up the hardware all I can help with is providing some sample programs and go through some of their code to figure out what parts of the underling hardware it relies on.
How are you handling the keyboard? are you keeping an image of the memory map for the keyboard area and just updating it with the make/break key info from the keyboard driver? I'd expect that to work for the ROM code and my old games.
Great work so far!
Robert.
Well, if you speak PASM, you could perhaps find my fault in the three mentioned files. I has to be some dumb thing like swapping register and address in a wrbyte/word/long (I had that), a missing # after a jmp or something like that.
Fortunately the OBEX Keyboard.spin driver already has a bitmap of active keys. All I have done is write an array of 64 bytes that maps a PS/2 keyboard bit to its TRS80 keyboard counterpart. I had to patch Keyboard.spin to set a rendezvous long to inform my I/O handler of key releases, ie. break codes, too, because otherwise it would be impossible to detect them. So the code in my io.spin that is waiting for a Z80 i/o command to handle also inspects this keyboard rendezvous long, and if it is non zero, reads the 64 keyboard bitmap flags and updates the Z80 map (8 bytes). The actual memory read from 3800-38ff is decoded into the 8 address lines and the logical or of the 8 bytes map is returned on the input port.
This all should work, but the keyboard driver itself is doing weird things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/26/2010 7:38:13 PM GMT
START DI LD SP,5300H LD A,'a' LD (3C00H),A LD A,(3C00H) CP 'a' JR Z,OKL LD HL,0 LD (PRSTR),HL .......; The Print routine took a 0 terminated string at HL and put it at screen address DE. This one was special since it would skip spaces to let the graphics behind show through. If the system didn't support lower case it would overwrite the JR SAME instruction with two NOP's so it would fall through.
PRSTR JR SAME PRLOP LD A,(HL) OR A RET Z CP 32 JR Z,OK1 CP 'a' JR C,OKPRT CP 7BH JR NC,OKPRT SUB 20H OKPRT LD (DE),A OK1 INC DE INC HL JR PRLOP SAME LD A,(HL) OR A RET Z CP 32 JR Z,OK2 LD (DE),A OK2 INC DE INC HL JR SAMEPost Edited (RobotWorkshop) : 3/30/2010 6:54:33 PM GMT
I have hacked lowercase, i.e. codes below 20h are ORed with 40h to make them display the upper case characters, but lowercase is possible too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
http://www.trs-80.com/wordpress/zaps-patches-pokes-tips/rom-ram-ports-calls-tokens-the-inside-stuff/
As I recall the keyboard wasn't fully decoded so that looking at the keyboard memory you'd see the same data in a couple different locations. I think I found the section of code in io.spin where you read the keyboard and map it to an image of the TRS-80 keyboard memory but I'm not fluent enough in PASM yet so I am still trying to make sense of it.
To get random numbers it would use the instruction ld a,r to read the refresh register. That would occur after the initial splash screen. I can see that it is in your emulator but was that part of any of the early code in your test cases?
Robert
Post Edited (RobotWorkshop) : 3/26/2010 9:40:30 PM GMT
I need to get your new LMM code working before you race ahead and I can't catch you!
Latest download above.
I changed Dracblade to DracbladeProp, Now it almost compiles.
Used Yaz80 instead of ZicogLMM
Failing at the start of the this routine
okay := yaz80.start(0, io.command_addr, @videoram_, 0)
I see the syntax has changed from
err := \cpu.start(@reg_base)
(cpu is the same as yaz80) with extra variables. In particular io.command is new and all the port addresses seem to have been moved into "io" instead of in the main program. And that includes the keyboard and I gather the keyboard is not working.
Have you got a CP/M version working with your latest yaz80 code, and if so, does it include the keyboard?
If not, what variables could I send to yaz80.start so it can work with CP/M?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
It was actually pretty tricky. They used the address lines A0-A7 directly to the keyboard rows and D0-D7 to the columns. So reading 3801 you get the first row, 3802 2nd, 3804, 3808 etc. But you could also read 2 keys at once, or even all keys. 38ff would read all keyboard rows and you could immediately see if any key was pressed. I mimic this by having 8 bytes of keyboard row data and checking the memory address that was accessed for bits 0..7, combining the addressed rows with OR.
Actually I'm not yet sure if I have to invert the logic to AND the inverted addressed rows together...
The R register is implemented for that very reason, yes. Many games used it as pseudo random value. It isn't tested at all by the exerciser code if you meant that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/27/2010 3:15:03 AM GMT
Hmm.. pasting yaz80 to your environment of io handling etc. is possible, but not easy. I wrote my own version of everything supported so far in io.spin. Actually the unmodified archive should work with a terminal like PST at 115k2. No VGA video yet and the PS/2 keyboard is giving me only 0s and 1s, i.e. ^@ and ^A. I haven't figured that bug yet.
If you want to run yaz80 in your environment, you would specify the address of the io_command variable in your i/o code as 2nd parameter, i.e. @io_command and the other parameters as 0s. Just don't ask me how far you will get with it. The i/o is still compatible to ZiCog, though. I intend to change it. See the other thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/27/2010 3:40:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The FDS isn't required anymore, because the info output is now displayed on the TV screen.
I included some CMD files for you to play with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
With a counter in DUTY mode the FRQx register sets the output pulswith. It's no a normal PWM because the frequency
changes with the pulswith, but for sound it's fine.
I don't really undestand if you need the voltages 0, 0.46 and 0.85 or the percentage to 1V, so I calculated both.
Andy
Thank you for the explanation. That is as easy as I expected it to be [noparse]:)[/noparse] The actual voltages would be interesting if you wanted to use my emulator to create TRS80 cassette tapes from within it. Otherwise I guess you would use a resistor voltage divider on the output pin to ensure your audio input doesn't get too high a level.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
mic plug, which you either plugged into a 276(?)-1008 amp or push the mic monitor switch on the tape deck?
PWM wasn't the method used then, I don't think. But maybe... I'm not sure.
Usually a 50% duty cycle square wave whose frequency was controlled by a countdown loop in ASM.
Except for certain sound effects which were loaded (at least by myself) from the cassette tape!
Got the pac-man game?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.
Coming soon. My open Propeller Project Pages and favorite links index.
0: 0.46V
1: 0V
2: 0.85V
3: 0V
Yeah [noparse]:)[/noparse]
I think so. I've got several hundred or thousand CMD files and never had the chance to look through all or even many of them.
You know, there once was trs80.org, and I was ambitious to download the internet to my PC anyway...
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The keyboard is still erratic and so playing the games is still impossible.
Galaxy has a nice attract mode, so you can at least look at something.
The ZIP includes some more games in the CMD subdirectory, as well as the required TRS80.ROM
Sound _might_ be working. I haven't found a definite pin to use on the DracBlade yet.
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.
Have fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/29/2010 8:55:41 AM GMT
I'm not sure what is wrong with the keyboard - I gather it works with the original keyboard but something changes and it doesn't work?
Re sound, if you are using TV then there are 4 or 5 pins you could use for sound. An onboard audio amp could be a simple 8 pin chip and a few components so might not make the board much bigger.
The "nightmare of changing to the modern sd SPI" is the reason I have not attempted it, but I imagine as cards get bigger it will have to happen for the dracblade code too.
The cog dependency bug is very strange.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I've been off the net for a week and come back to find a TRS80 emulator in the can. I also had a Video Genie back in the day. Very nostalgic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The keyboard works in the CP/M environment. I put the translation code for CTRL keys and some specials in i/o and constat/conin also read the PS/2 keyboard now. So the problem is in what I do different in the TRS80 environment. Has to be some trashing of memory out of bounds...
Hmm. Okay, I use 1pinTV for the black&white output, so there's plenty of pins. I only didn't know that you could use a pin of a VCFG group for other purposes on another cog! That makes it easy.. No, I don't use VGA here because I have no spare monitor at the moment.
Yeah, _very_ strange, but then Cluso99 said it was coded to squeeze out all performance one could get. I saw it uses the cog's counters and PSHA registers to read/write bits. No bit banging in software like the Femto code did.
If you can make sure that the SD code is in the first cog, you will have a great win: bigger (cheaper) SD cards, FAT32 support and quicker loading times. I think the hairy monster was wanting to try to embed DracBlade XMM and the SD code in one cog!? If he manages that, it'll be _very_ useful. I think in that case I or someone else should do the same thing for other architectures, namely the RamBlade and perhaps the TriBlade, too. It is nice to have I/O objects using the same semantics for the various hardware and makes the life of us application developers easier [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It's looking good: sound works like a charme. I used pin 20 of the DracBlade, just after the VGA resistor. Keyboard is working halfways: it reacts on keypresses, but delivers 8 characters instead of 1. Will fix that now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/29/2010 2:13:20 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wait a moment, I'll reupload and post the link here.
Here is the correct link now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/29/2010 2:12:58 PM GMT
I had to. That was kind of funny guys.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
It works - sort of. The keyboard SHIFT function is not yet right, meaning you can't reach all keys. Also, sometimes the recognition of a key is a little flaky, probably because the status is changed after the i/o cog detects a change is under the way. I have to look closer into the original Keyboard object to see how to improve that.
Anyway. You can play games now. I just zapped away a few aliens in Galaxy Invasion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Do NOT taunt happy pullmoll
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Have fun! *back to playing time pilot*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.