Drac: I am really not sure of the implications. I just recall there was something that was not wise to do.
Jurgen: Attached is the TriBlade driver. In the RamBlade, because it does not shift the address bits they do not have to be double buffered. Also, since there is a free instruction between the address and data read, the address can be incremented for free. Note: TriBlade v204 has not been released - it has a comment fixed for SDA & SCL definition only.
The in/out instructions require the tristate of the address/data pins for the TriBlade (as I said) because this may cause an SD card access which would cause a conflict. For now, just make the RamBlade the same although I am sure I found a way for this not to be required but it required a change elsewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Drac: I am really not sure of the implications. I just recall there was something that was not wise to do.
Jurgen: Attached is the TriBlade driver. In the RamBlade, because it does not shift the address bits they do not have to be double buffered. Also, since there is a free instruction between the address and data read, the address can be incremented for free. Note: TriBlade v204 has not been released - it has a comment fixed for SDA & SCL definition only.
The in/out instructions require the tristate of the address/data pins for the TriBlade (as I said) because this may cause an SD card access which would cause a conflict. For now, just make the RamBlade the same although I am sure I found a way for this not to be required but it required a change elsewhere.
It doesn't look like then #endif blah does make a difference.
I'll add the TriBlade driver to the CVS and next archive then, as well as the RamBlade thingy. Tri stating is in place on all ops that could cause other cogs to do I/O.
Edit: Wow, the RamBlade's read access is really simple [noparse]:)[/noparse] Doesn't even need a temp. The write is a little longer, but still ok. All fits well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 12:17:24 PM GMT
Toby Seckshund said...
From fading memory the Nascom used to run a 10000 for next loop in 17 secs, but then I cannot remember if that was at its 2MHz or 4MHz setting.
FYI It currently takes 24 seconds on the DracBlade in MBasic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Just having looked at the source of the tokenizer. If you use a #endif or whatever that does not expect a parameter, it completely ignores anything after the first space after the option. So #endif fred would ignore the fred. If you used #endif 'fred then the highlighter will highlight the end as a comment, but the compiler ignores it anyway. (The highlighter is not #aware yet)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC said...
Just having looked at the source of the tokenizer. If you use a #endif or whatever that does not expect a parameter, it completely ignores anything after the first space after the option. So #endif fred would ignore the fred. If you used #endif 'fred then the highlighter will highlight the end as a comment, but the compiler ignores it anyway. (The highlighter is not #aware yet)
Is there any specific reason why it then fails at the 2nd word after the first blank?
#endif 'fred was here -- fails
#endif 'fred_was_here -- succeeds
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
BradC said...
Just having looked at the source of the tokenizer. If you use a #endif or whatever that does not expect a parameter, it completely ignores anything after the first space after the option. So #endif fred would ignore the fred. If you used #endif 'fred then the highlighter will highlight the end as a comment, but the compiler ignores it anyway. (The highlighter is not #aware yet)
Is there any specific reason why it then fails at the 2nd word after the first blank?
#endif 'fred was here -- fails
#endif 'fred_was_here -- succeeds
Yep.. it does not do parameters with spaces in them. Anything except #warn/#error/#info stops parsing the parameter when it hits a space and just feeds it though as text.
Looks like I need to massage the tokenizer a little more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
pullmoll: Yes, that is why I said the RamBlade could use fetch inline and save the call/ret instruction as well. Only 2 more longs required because you save the call and increment, but add 4 for the access and increment in it's place. This is another 12 clocks shaved for every instruction fetch. However, you still need to have the routine for read data unless you inline that also, which then saves the ret as well.
While looking at the code, I saw that it still needs a tidy at the RamBlade access. I was having an access problem that turned out to be a faulty uSD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I want to emulate the TRS80 on the DracBlade. What I would need was a TV and/or VGA driver capable of 64x16 characters using a 6x12 pixel chargen. I saw that Cluso99's Debug_1pinTV does 64x25, so 64x16 should be possible as well. It wouldn't need any terminal code, as the video RAM is at a fixed address and would be modified by the Z80 only. The question is: will it be possible to fit 128 characters with 12 bytes each? If not, the chargen could be restricted to 6x8 pixels (as the real ROM was) and there would be no descents on g,p,q and y (the unmodified TRS80 didn't have them either).
The second thing is probably more complicated, or perhaps not. The 2nd 128 characters are block graphics with a 2x3 raster. That means a pseudo pixel graphics of 64x2=128 by 16x3=48 pixels. I guess these graphics could be derived from the code on the fly somehow, but I don't know if there's enough time to do it in the active phase. It probably needs some longs with none,left,right,both pixel set that would be indexed by the character code and scan row.
The bits are 0:top, left 1:top, right, 2: middle, left, 3:middle right, 4:bottom left, 5:bottom right. Bit #6 is irrelevant, i.e. the block graphics is repeated once.
Is it hopeless to believe this is doable, or does it perhaps require a 2 cog solution with separate scanline renderer and scanline emitter?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Cluso99 said...
pullmoll: Yes, that is why I said the RamBlade could use fetch inline and save the call/ret instruction as well. Only 2 more longs required because you save the call and increment, but add 4 for the access and increment in it's place. This is another 12 clocks shaved for every instruction fetch. However, you still need to have the routine for read data.
Hmm.. I will try to make rd_opcode inline on the RamBlade later on, at least for the primary opcode. The way you chose the I/O pins is definitely the best of all [noparse]:)[/noparse] I'm curious to get that tiny board in my hands.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
TRS80: My 1-pinTV can do 64x16 (needs a parameter change or just leave the top/bottom 2 lines blank). 64 columns will work at 96MHz (6MHz xtal) or at 80MHz if you remove inverse video. My driver is text only. The screen buffer is not setup as a pixel buffer. If you are not using graphics, then just use the 8x8 font. You will not fit a 6x12 font or a 6x8 font in the driver. The x12 will not fit because of size (needs ano 512 bytes in cog!). The 6x will not work because of speed unless you remove the inverse video.
For the graphics: If you used 12K of screen buffer in hub and held it as pixels you could do it. Alternatively, you probably could use 2 cogs to do it. Potatohead may have some tricks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: you may miss my post on the prev page.
TRS80: My 1-pinTV can do 64x16 (needs a parameter change or just leave the top/bottom 2 lines blank). 64 columns will work at 96MHz (6MHz xtal) or at 80MHz if you remove inverse video. My driver is text only. The screen buffer is not setup as a pixel buffer. If you are not using graphics, then just use the 8x8 font. You will not fit a 6x12 font or a 6x8 font in the driver. The x12 will not fit because of size (needs ano 512 bytes in cog!). The 6x will not work because of speed unless you remove the inverse video.
For the graphics: If you used 12K of screen buffer in hub and held it as pixels you could do it. Alternatively, you probably could use 2 cogs to do it. Potatohead may have some tricks.
I saw your post. I'll fix any outstanding issues with the RamBlade once it arrives.
TRS80: The characters are in the upper 8 of the 12 scanrows IIRC. Inverse video isn't needed, but the block graphics, which is most probably worse than inverse. Wasting 12K screen buffer is certainly too much, so I think I should try a 2 cog solution with a bitmap scanline renderer, or perhaps 2 bitmap scanlines to be one line ahead with the rendering cog. I think the bitmap video could be the simplest of all, as there is no indexing, but just sequentially shifting out the bitmap data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
There is a downside to RamBlade because of the speed gains... The data pins conflict with the download pins, so you should not download and then go straight into ZiCog until the propplug is removed! The alternative is to put a delay and wait for a character from the other serial (or tv/kbd) port.
That was the reason I wanted to get file transfers to the SD running under SphinxOS (or xmodem). Mpark implemented a nice simple FTP and a short C program although I never tested it.
You may receive the RamBlade by the end of this week if the posties are on the job LOL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
There is a downside to RamBlade because of the speed gains... The data pins conflict with the download pins, so you should not download and then go straight into ZiCog until the propplug is removed! The alternative is to put a delay and wait for a character from the other serial (or tv/kbd) port.
That was the reason I wanted to get file transfers to the SD running under SphinxOS (or xmodem). Mpark implemented a nice simple FTP and a short C program although I never tested it.
You may receive the RamBlade by the end of this week if the posties are on the job LOL.
Propplug? What propplug? I have only RS232 cable here. Do I need to convert it to TTL level myself then?
I now understand why you have SI and SO on pins 23,22 - to not conflict with the RAM data.
I'll do debugging on the DracBlade or perhaps my PropRPM, and have a look at SphinxOS and how to load the yaz80 from there.
PS: Now going to drink an entire can of coffee and attack that ***** adc16/sbc16 bug in all ernest [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
After finally fixing the sbc16/adc16 bug (it was, of course, one of the most stupid kind of bugs) I'm now looking at the group daa,cpl,scf,ccf and I don't see it. Perhaps you see it? I compare to zicog's working versions of the 4 opcodes and still don't see the reason why mine fail.
' -------------------------------------------------------
z_daa ' 27
mov tmp, A
mov aux, A ' save for auxiliary flag test
and tmp, #15 ' isolate low nibble of accumulator
mov daa_adj, #$06 ' +$06
test F, #NF WZ ' test negative flag
negnz daa_adj, daa_adj ' -$06
test F, #HF WZ
cmp tmp, #$09+1 WC ' is nibble > $9 ?
if_nc_or_nz add A, daa_adj ' aux was set or nibble is > $9 => add $06 or -$06
shl daa_adj, #4 ' +$60 or -$60
test F, #CF WZ
cmp A, #$99+1 WC ' is data > $99 ?
if_nc_or_nz add A, daa_adj ' carry was set or data is > $99 => add $60 or -$60
and F, #(NF | CF) ' preserve old CF and NF
cmp A, #$99+1 WC
if_nc or F, #CF ' set carry if result > $99
xor aux, A
and aux, #HF WZ ' if bit #4 of result changed
or F, aux ' set the auxiliary carry flag
test A, #$80 WZ ' get sign bit #7
muxnz F, #SF ' set S on sign
and A, #$ff WZ, WC ' get zero and parity flags
muxz F, #ZF ' set Z on zero
muxnc F, #PF ' clear P on parity
jmp #fetch
' -------------------------------------------------------
z_cpl ' 2f
xor A, #$ff
or F, #(HF | NF) ' set the H and N flags
jmp #fetch
' -------------------------------------------------------
z_scf ' 37
or F, #CF ' set the C flag
andn F, #(HF | NF) ' clear the H and N flags
jmp #fetch
' -------------------------------------------------------
z_ccf ' 3f
test F, #CF WC ' get the C flag into the carry
muxc F, #HF ' set the H flag if C was set
xor F, #CF ' toggle the C flag
andn F, #NF ' clear N flag
jmp #fetch
It can't be that much, probably just a bit or a typo. A contradiciton between comment and PASM opcode...
Edit: GOTCHA! It was in DAA where I compared against A and also adjusted A. This has to be done differently, comparing the original value and adjusting the new value.
Now if I'm not totally wrong, this makes YAZ80's Z80 emulation perfect - opcode wise. All documented opcodes are working. Almost all undocumented opcodes too. The only exception is the SET <reg8>= <bit>,(<ix,iy>+disp8).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/23/2010 12:53:16 PM GMT
YAZ80 now supports finding the CP/M files in any type of FAT root directory.
FAT32 files beyond the first cluster are untested, though.
FAT12 is untested (don't have a < 32MB SD card)
This should make it much easier for you Windows people to prepare an SD card
The filenames have to be BOOT.DSK for the boot image that is put at Z80 memory $ff00 and A.DSK, B.DSK ... H.DSK for the 8 hard disk images.
The YAZ80 emulates all Z80 opcodes, including the undocumented ones.
Enjoy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
All the opcodes? Fantastic. Do you have an upated download?
Also the FAT32 sounds good - there have been times I've forgotten to format on fat16 and the cart hasn't worked, so fat32 (which is the windows default) would be a lot better.
Dr_Acula said...
All the opcodes? Fantastic. Do you have an upated download?
Yes, all of them, except I broke set/res n,(ix/iy+disp8) in a last minute change, but that'll be easy to fix.
Dr_Acula said...
Also the FAT32 sounds good - there have been times I've forgotten to format on fat16 and the cart hasn't worked, so fat32 (which is the windows default) would be a lot better.
Yup. I tried with a 2GB card with 4K clusters and it works fine. The files still have to be contiguous.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Baggers said...
ZX81 and/or ZXSpectrum emulation ( TX1000 or whatever it was called in the states )
pullmoll said...
Baggers said...
pullmoll, are the interrupts implemented?
No, they arent. What would you need them for?
That will be difficult without cycle counting, because you won't get a stable picture I fear. I can implement interrupts by exporting a long that would be read at every instruction and would then allow to do either NMI or IRQ depending on 2 bits. Of course this would be optionally, because it certainly slows down the emulation.
The next build should contain a #define for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
There are some TRS-80 Programs that used Interrupts. I know I had written a clock program for the Model I/III that used them. It had to check what system it was running on since the interval was different on those two systems. What model are you trying to emulate? Most of the programs would run fine on either system. It was mainly the disk operating system that needed tweaks because the Model I had all memory mapped I/O but the III used the I/O ports for the disk controller.
RobotWorkshop said...
There are some TRS-80 Programs that used Interrupts. I know I had written a clock program for the Model I/III that used them. It had to check what system it was running on since the interval was different on those two systems. What model are you trying to emulate? Most of the programs would run fine on either system. It was mainly the disk operating system that needed tweaks because the Model I had all memory mapped I/O but the III used the I/O ports for the disk controller.
Robert
The TRS80 clock interrupt and FDC interrupt, sharing the same one IRQ (RST 38 vector). The clock was 40Hz if I'm not totally wrong. Memory mapped IRQ status register at $37EF with one bit for the clock, and one bit for the FDC. I will try to emulate the Model I with Level 3 Basic (12K) and probably without the FDC, because emulating that one is a lot of work. It should suffice to shuffle a cassette image into main memory and tweak a vector or two to make the programs go. No interrupts necessary for this setup.
It will need a prop with SD card and external memory, so any of the Blades should work. Sound is something I did not yet look into. It needs a 3 level DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Thanks pullmoll, don't need to worry too much about cycle accuracy, because I'd make the ZX81 emulation point to a screen buffer, which would then drawn by the screen display driver, not the actual ZX81.
Spectrum version is a bitmap anyway, and we already have drivers for that [noparse]:D[/noparse]
Very cool! I'm never written any emulators but I have a bunch of software that I wrote for the TRS-80 systems. There were several full arcade games (written in assembly) and other programs that I can see about digging out of storage.
RobotWorkshop said...
Very cool! I'm never written any emulators but I have a bunch of software that I wrote for the TRS-80 systems. There were several full arcade games (written in assembly) and other programs that I can see about digging out of storage.
Hey mate, I wrote games in the early 1980s too. For the Colour Genie, a system not too widely spread, except in Germany and in Australia. I wrote some stuff for the TRS80, too, but nothing worth mentioning.
I'm putting the things together now: SD support for reading the TRS80.ROM file from any FAT. Video cog and renderer cog for the TRS80 graphics. Modified read/write handlers that protect ROM against overwriting and detect writes to the screen buffer. Doesn't run yet.. tough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Comments
But it still compiles ok. Can you give me an example that might break the compiler?
#endif 'mydef changes the color of 'mydef
#endif mydef does not change the color.
Both seem to compile ok. But to be safe, maybe then one with ' at the beginning?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/21/2010 10:42:53 AM GMT
Jurgen: Attached is the TriBlade driver. In the RamBlade, because it does not shift the address bits they do not have to be double buffered. Also, since there is a free instruction between the address and data read, the address can be incremented for free. Note: TriBlade v204 has not been released - it has a comment fixed for SDA & SCL definition only.
The in/out instructions require the tristate of the address/data pins for the TriBlade (as I said) because this may cause an SD card access which would cause a conflict. For now, just make the RamBlade the same although I am sure I found a way for this not to be required but it required a change elsewhere.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/21/2010 11:27:15 AM GMT
It doesn't look like then #endif blah does make a difference.
I'll add the TriBlade driver to the CVS and next archive then, as well as the RamBlade thingy. Tri stating is in place on all ops that could cause other cogs to do I/O.
Edit: Wow, the RamBlade's read access is really simple [noparse]:)[/noparse] Doesn't even need a temp. The write is a little longer, but still ok. All fits well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 12:17:24 PM GMT
FYI It currently takes 24 seconds on the DracBlade in MBasic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Is there any specific reason why it then fails at the 2nd word after the first blank?
#endif 'fred was here -- fails
#endif 'fred_was_here -- succeeds
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yep.. it does not do parameters with spaces in them. Anything except #warn/#error/#info stops parsing the parameter when it hits a space and just feeds it though as text.
Looks like I need to massage the tokenizer a little more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
While looking at the code, I saw that it still needs a tidy at the RamBlade access. I was having an access problem that turned out to be a faulty uSD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/21/2010 1:05:23 PM GMT
The second thing is probably more complicated, or perhaps not. The 2nd 128 characters are block graphics with a 2x3 raster. That means a pseudo pixel graphics of 64x2=128 by 16x3=48 pixels. I guess these graphics could be derived from the code on the fly somehow, but I don't know if there's enough time to do it in the active phase. It probably needs some longs with none,left,right,both pixel set that would be indexed by the character code and scan row.
The bits are 0:top, left 1:top, right, 2: middle, left, 3:middle right, 4:bottom left, 5:bottom right. Bit #6 is irrelevant, i.e. the block graphics is repeated once.
Is it hopeless to believe this is doable, or does it perhaps require a 2 cog solution with separate scanline renderer and scanline emitter?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 1:21:19 PM GMT
Hmm.. I will try to make rd_opcode inline on the RamBlade later on, at least for the primary opcode. The way you chose the I/O pins is definitely the best of all [noparse]:)[/noparse] I'm curious to get that tiny board in my hands.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
TRS80: My 1-pinTV can do 64x16 (needs a parameter change or just leave the top/bottom 2 lines blank). 64 columns will work at 96MHz (6MHz xtal) or at 80MHz if you remove inverse video. My driver is text only. The screen buffer is not setup as a pixel buffer. If you are not using graphics, then just use the 8x8 font. You will not fit a 6x12 font or a 6x8 font in the driver. The x12 will not fit because of size (needs ano 512 bytes in cog!). The 6x will not work because of speed unless you remove the inverse video.
For the graphics: If you used 12K of screen buffer in hub and held it as pixels you could do it. Alternatively, you probably could use 2 cogs to do it. Potatohead may have some tricks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I saw your post. I'll fix any outstanding issues with the RamBlade once it arrives.
TRS80: The characters are in the upper 8 of the 12 scanrows IIRC. Inverse video isn't needed, but the block graphics, which is most probably worse than inverse. Wasting 12K screen buffer is certainly too much, so I think I should try a 2 cog solution with a bitmap scanline renderer, or perhaps 2 bitmap scanlines to be one line ahead with the rendering cog. I think the bitmap video could be the simplest of all, as there is no indexing, but just sequentially shifting out the bitmap data.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
That was the reason I wanted to get file transfers to the SD running under SphinxOS (or xmodem). Mpark implemented a nice simple FTP and a short C program although I never tested it.
You may receive the RamBlade by the end of this week if the posties are on the job LOL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Propplug? What propplug? I have only RS232 cable here. Do I need to convert it to TTL level myself then?
I now understand why you have SI and SO on pins 23,22 - to not conflict with the RAM data.
I'll do debugging on the DracBlade or perhaps my PropRPM, and have a look at SphinxOS and how to load the yaz80 from there.
PS: Now going to drink an entire can of coffee and attack that ***** adc16/sbc16 bug in all ernest [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/21/2010 2:40:05 PM GMT
' ------------------------------------------------------- z_daa ' 27 mov tmp, A mov aux, A ' save for auxiliary flag test and tmp, #15 ' isolate low nibble of accumulator mov daa_adj, #$06 ' +$06 test F, #NF WZ ' test negative flag negnz daa_adj, daa_adj ' -$06 test F, #HF WZ cmp tmp, #$09+1 WC ' is nibble > $9 ? if_nc_or_nz add A, daa_adj ' aux was set or nibble is > $9 => add $06 or -$06 shl daa_adj, #4 ' +$60 or -$60 test F, #CF WZ cmp A, #$99+1 WC ' is data > $99 ? if_nc_or_nz add A, daa_adj ' carry was set or data is > $99 => add $60 or -$60 and F, #(NF | CF) ' preserve old CF and NF cmp A, #$99+1 WC if_nc or F, #CF ' set carry if result > $99 xor aux, A and aux, #HF WZ ' if bit #4 of result changed or F, aux ' set the auxiliary carry flag test A, #$80 WZ ' get sign bit #7 muxnz F, #SF ' set S on sign and A, #$ff WZ, WC ' get zero and parity flags muxz F, #ZF ' set Z on zero muxnc F, #PF ' clear P on parity jmp #fetch ' ------------------------------------------------------- z_cpl ' 2f xor A, #$ff or F, #(HF | NF) ' set the H and N flags jmp #fetch ' ------------------------------------------------------- z_scf ' 37 or F, #CF ' set the C flag andn F, #(HF | NF) ' clear the H and N flags jmp #fetch ' ------------------------------------------------------- z_ccf ' 3f test F, #CF WC ' get the C flag into the carry muxc F, #HF ' set the H flag if C was set xor F, #CF ' toggle the C flag andn F, #NF ' clear N flag jmp #fetchIt can't be that much, probably just a bit or a typo. A contradiciton between comment and PASM opcode...
Edit: GOTCHA! It was in DAA where I compared against A and also adjusted A. This has to be done differently, comparing the original value and adjusting the new value.
Now if I'm not totally wrong, this makes YAZ80's Z80 emulation perfect - opcode wise. All documented opcodes are working. Almost all undocumented opcodes too. The only exception is the SET <reg8>= <bit>,(<ix,iy>+disp8).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/23/2010 12:53:16 PM GMT
FAT32 files beyond the first cluster are untested, though.
FAT12 is untested (don't have a < 32MB SD card)
This should make it much easier for you Windows people to prepare an SD card
The filenames have to be BOOT.DSK for the boot image that is put at Z80 memory $ff00 and A.DSK, B.DSK ... H.DSK for the 8 hard disk images.
The YAZ80 emulates all Z80 opcodes, including the undocumented ones.
Enjoy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/23/2010 9:42:48 PM GMT
Also the FAT32 sounds good - there have been times I've forgotten to format on fat16 and the cart hasn't worked, so fat32 (which is the windows default) would be a lot better.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes, all of them, except I broke set/res n,(ix/iy+disp8) in a last minute change, but that'll be easy to fix.
Yup. I tried with a 2GB card with 4K clusters and it works fine. The files still have to be contiguous.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Regards,
T o n y
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
That will be difficult without cycle counting, because you won't get a stable picture I fear. I can implement interrupts by exporting a long that would be read at every instruction and would then allow to do either NMI or IRQ depending on 2 bits. Of course this would be optionally, because it certainly slows down the emulation.
The next build should contain a #define for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Robert
The TRS80 clock interrupt and FDC interrupt, sharing the same one IRQ (RST 38 vector). The clock was 40Hz if I'm not totally wrong. Memory mapped IRQ status register at $37EF with one bit for the clock, and one bit for the FDC. I will try to emulate the Model I with Level 3 Basic (12K) and probably without the FDC, because emulating that one is a lot of work. It should suffice to shuffle a cassette image into main memory and tweak a vector or two to make the programs go. No interrupts necessary for this setup.
It will need a prop with SD card and external memory, so any of the Blades should work. Sound is something I did not yet look into. It needs a 3 level DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/24/2010 6:55:19 PM GMT
Spectrum version is a bitmap anyway, and we already have drivers for that [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
http://ganley.org/software/trs80.html
http://www.tim-mann.org/trs80faq.html
http://www.vavasour.ca/jeff/trs80.html
Once it is done perhaps you can run this....
I've written a few myself. No, really [noparse]:)[/noparse] The first one I wrote was on an AT286 4.77/10MHz and written in x86 assembler...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'm putting the things together now: SD support for reading the TRS80.ROM file from any FAT. Video cog and renderer cog for the TRS80 graphics. Modified read/write handlers that protect ROM against overwriting and detect writes to the screen buffer. Doesn't run yet.. tough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/24/2010 8:16:11 PM GMT