Re Toby "
I have mused on the decoder and latch bits of Dracblade, they will fit int a XC9536XL ( LCD not implimented ) One spare pin and only 66% used innards, although I havent floorplanned it yet. "
Fascinating! That could save 4-5 chips.
I've got a new board on the way that is slightly different in that the 4 pins that control the SD card are contiguous (12-15) and the 4 pins for the 138 are also contiguous (8-11). Also I changed the 138 outputs slightly. The new board is on the way (also includes switchers for both 5V and 3V3 - I'm hooked on switchers!) and once I make a few code changes and get it working I can call this a finished design ready for its own thread. I've still got a few things to test eg:
* LCD display
* The second serial port
* TV out (with Cluso's intriguing suggestion of doing TV with one pin?)
* Double check the VGA resistors as they seem to be round the wrong way (they were copied from the PockeTerm schematic and are using PockeTerm code and the green looks ok)
* Bring out 4 header pins for I2C
A XC9536XL sounds intriguing. $1.07 from digikey which may well end up cheaper than the chips it replaces. I know absolutely nothing about these chips, especially the complexities of how you program them. Do you program them with serial, RS232, USB or via a special programmer or some other way?
At the most fundamental level, the CPLD has 12 inputs, and it has 19 outputs. 25 outputs if you include the LCD display. I see the chip has 34 I/O pins.
There may be scope to drive the LCD display differently - the 4 data nibble lines could be pins 0-3 on the prop, the rd/wr could be pin 4 on the prop, and the enable could be an inverted output from a 138. Then the display would ignore data lines unless it was selected. I need to look at the LCD specs again, but perhaps the 4th latch is not needed. Indeed it could have been done using the third latch but I wasn't confident driving a 5V LCD display using 3V3 logic levels so the main function of the 4th latch is as a level translator.
Perhaps the LCD display is not needed? They cost $16. Graphics LCD displays can display twice as many rows for the same price. Or for $33 you can get small TV screens (though I need to check the resolution looks ok). And then there is the I2C bus - if that comes out externally, you can always add I2C to parallel with one chip and drive a display that way.
Going back to testing Z80, I've been running the EXZ80DOC program but it is failing the checksum on the first set of tests, and in the middle are so many tests that it hangs on an overnight test, and I'm not sure if it is crashing or just taking several days to get there. Maybe I'll need to set the triblade going on a dedicated PC for comparison as this takes so long. I got this checksum error on the triblade on the first test:
Cluso - where did we get to with the discussion about the floppy drive images? I'm thinking about making one drive (?drive F for Floppy) a floppy image, so it would be possible to import disk images straight from the SIMH. I can't recall whether there is the code working to work with unprocessed floppy disk images.
Drac: Knowing your hate for SMT, I hate to tell you but the CPLD is SMT. The best you can do is use PLCC44 and a t/hole socket, but you will find this will be more costly than the chip!!! Programming is via a JTAG interface (4 pins). I still think a 2nd prop is the simplest, if not a bit more expensive.
I think the 1-pin TV is in the OBEX. I should try it out (time??).
VGA resistors - check the Prop ProtoBoard circuit.
There is currently no code to use unprocessed floppy images although it is relatively simple. However, the code we are now using has no floppy support. There is an #ifdef to turn it back on but then its 8 floppies and 2 HD. Suggest we just reformat with VB or SIMH and post the files, or Xmodem them across.
re the CRCC bug, it is possibly because heater has not got all the flags correct for the Z80. You will need him to answer that.
Is your code ready for inclusion in a V1.0 release? I was not going to hold up the release for RamBlade as I'd like to get it out quickly before I get burried again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The reason I dislike smt (for prototyping and small runs) is that DIP chips can be recycled so easily from other projects. Also debugging is simpler if a chip has possibly been zapped.
Today got text on the 20x4 LCD display. It is still messy text as the display is just printing it rather than acting as a terminal that scrolls up 1 if on the last line, but I just have to translate some Z80 opcodes to spin. All good fun!
Re version 1.0 - my code is not ready yet as I'm going to be changing it soon when the new board arrives as the pins are different. There are also large parts of the code that are the same for the triblade and dracblade but not heaters original emulation, and I'm not sure how to do an #ifdef 'a or b', so the alternative is cut and paste large sections of code and duplicate them. So if you go ahead and release it I can take that and do a 'clean' revision of the code.
Cluso99 said...
Drac: Knowing your hate for SMT, I hate to tell you but the CPLD is SMT. The best you can do is use PLCC44 and a t/hole socket, but you will find this will be more costly than the chip!!! Programming is via a JTAG interface (4 pins). I still think a 2nd prop is the simplest, if not a bit more expensive.
Ray's right about 2nd Prop unless your using a tiny SMT CPLD or an old style PAL. PLCC44's are monsters.
A 4-8 megabyte Propeller solution is quite easy if you have need/room and are willing to do a little work.
Speed will always be an issue for Propeller XMM regardless of the approach though.
Drac: If you use the PLCC and socket (yes Jazzed is right - they are big, but no more than a DIP40 prop chip), you can recover the CPLD from the socket with a socket puller.
BTW when I last looked the PLCC sockets had staggered 0.1" double row pins so you cannot use vero board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater said...
"bst optimises so if it's not used it's probably not in the compiled code"
As far as I can tell this is NOT true for LONGs in PASM. I've just tried it again with simple test prog with all optimizations turned on.
For sure it would be very bad to just remove along from the middle of PASM which could well beak some code that depends on the offsets of things. Unlike Spin it is very dangerous to remove away code from assembly languages.
Absolutely correct. At the moment the only thing bst[noparse][[/noparse]c] excludes is unused spin methods. The latest -pre versions of bst will tell you if a global or local variable in a spin block is unreferenced, but it certainly does not touch them.
No guesswork is even performed on DAT blocks. Just too many ways to do funky tricks for the compiler to try and figure out what is going on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Hi Leon. Looks very interesting. Thanks for the photo. Is there anything else that is needed, eg a download cable of some sort?
I got the LCD working! See attached photo. So output goes to the vga display, the LCD display and to the serial port and hence terminal program. You can use one or as many of these as you like (it has been very handy when debugging for instance to send the decimal value of bytes to one type of display and send the actual byte to another).
Attached, warts and all, is a zip of the files. It is a muddle and contains a few mildly frustrated comments about wierd bugs (eg why do 'if' statements in spin sometimes change the value of the variable they are testing if the variable is a global variable, but not if copied to a local variable?). But I've found solutions and it does all work.
Cluso, re your comments on the floppy disk images, yes, it is easy to do downloads via xmodem for one or two files, or copy a complete image over for bulk transfer of files.
In the last hour I've actually been using the board for useful things, and I must say that it is so much easier with all this disk space compared with the N8VEM and its single 448k drive. Now I can fit wordstar and a programming language all on one disk!
I've got an old Xilinx cable you can have, and an XC9536 demo board. Xilinx gave them to me at a seminar many years ago. I've got a newer cable I use. You need a parallel port for the cable.
The chip on that demo board is in a BGA package, it's tiny!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
No problem with parallel, but once my schematic is stable you could always program the chips and send them out as part of a (hypothetical) super small single prop board. So perhaps hang on to the parts for the moment. I'm quite happy with DIP in a way, but one could envisage the smallest prop, a micro sd, a surface mount CPLD, and given one can probably get away with 0V/3V3 as an RS232 as long as there are the appropriate resistors, leave out the max232. Then it would be - hmm - prop, eeprom, cpld, memory chip.
Thinking of memory chips, there is most of the chip sitting there unused, and some time back Cluso had a demo working of CPM 3 or something similar that used banked memory. I think it was primarily designed for different 'users' on the same system. It could be something fun to do since one 'user' could be the local keyboard/vga, the second could be the first serial port to a terminal program, and the third 'user' could be via the other serial port to (say) a propeller PockeTerm.
I'm bursting at the moment with crazy ideas! eg - shift the sd card select from a dedicated prop pin over to the 138. That frees another pin. I'm coming to think that 'output' pins on a prop are easy, as you can always add latches etc (I've got 7 unused pins) and pwm out them for analog or digital. But 'input' pins are precious, especially if they are polling asynchronous data. This is the strength of the prop - the ability to poll a keyboard, a couple of serial ports and something else all at the same time. I'd like a spare pin to read some analog data. In particular, the analog data from an audio waveform and then see if it is possible to get that nifty bell modem code working as audio. Then via handheld radios. Then directly via radio. And/or, infrared and have the ability to detect the raw noisy RF input and do clever things like filter out the mains frequency at 50 or 60Hz via some filtering.
As you can tell, I'm now hopelessly hooked on the Propeller!!
My assumption that the LCD was some debug help was obviously wrong, and so the 9536 falls down on pin count. A 9572 in 84 pin guise would hold no advantage over a real prop in area. I was just looking for an excuse to put another small bit of learning onto another. I didn't know that you hated SMT so much either, you have seen my efforts, state of the art miniturization (pre 1970s). The thru hole sockets are expensive and double the area, also they do a mind bending pin-order-dance in the corners. It was Leon's artical that I based my experimental bd on, with Xilinx Mk3 JTAG parallel interface ( they publish cct ). I should turn the interface '126s into a CPLD project, just for the incestious irony.
The LHS is JTAG, middle is 9536/72 PLCC44 with PSU and clock options, RHS is just a few is and outs. The remote bd is fo PLCC84 9572s etc, there used to be a 95108 and a 95144 but they seem to have dissapeared, and the 72 is 5V only. This was destined for the Nascom rebuild.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
The LCD isn't essential - just useful for battery powered CP/M. I don't really dislike SMT - it is just they are not the best for prototyping. Maybe once a board has reached a stable design. Oh, and when it comes to miniaturisation, Cluso has so comprehensively trumped anything that I could do that there is no point in even trying *grin*!
I do like the idea of hybrids. Worth exploring further...
Amontec's Chameleon device (another one!) uses a Xilinx CoolRunner chip to emulate all sorts of JTAG interfaces, via adapter boards, by reprogramming it. They gave me one some years ago to try out on an ARM board I designed, and I've used it with Xilinx chips via a simple home-made adapter.
I remember someone in the press calling the Nascom the NASty COMputer.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
I've been pondering some real world interface for the triblade and dracblade. While the prop can do analog I/O, both these boards have run out of pins (unless you add another prop of course) But there was mention on another thread recently about using the two lines to the EEPROM as an I2C bus.
Back in the olden days ADC and DAC was complicated and needed dual rail power supplies etc. Pondering a minimum circuit for an I2C ADC, it is VSS VCC, input, clock and data. 5 pins, and indeed such a chip does exist (indeed many do). $2 from Farnell with free shipping:
Is there a catch as it seems too simple given the I2C drivers are already in the obex.
And a question - would it be possible two add two ADC chips on the same bus, or would their addresses conflict? (and therefore would it maybe be better to get one with 4 or 8 inputs?)
I'd be most grateful for an explanation re cogs. I put in another uart object and it seems I've run out!
I might be missing one, but I've got
1 for the keyboard
1 for the first uart
1 for the zicog
2 for the vga driver
1 for the ram driver (same as cluso's tbp2)
1 for fsrwfemto (sd card).
Hmm - that makes 7 so I must be missing one.
I put in a little trace at the beginning
PUB start | i
'waitcnt(clkfreq*1 + cnt) 'delay (so you can get PropTerminal active) <=== 1 secs
current_block_number := -1 'No SD block read into buffer yet so set invalid value
'Start the terminal
i:=UART.start(31,30,0,baud) 'start the uart Tx and Rx and set the baud rate
uart.dec(i) ' cog number
crlf
which returns a value of "2". The code in the uart object is
okay := cog := cognew(@entry, @rx_head) + 1
So I'm not sure if this is returning the actual cog number or the cog number plus 1
Is a cog running to do the bootup I2C to the eeprom by any chance?
I don't think any of these can be stopped. Help would be most appreciated!
Don't forget our top level code is zicog_cpm.spin (assuming you have not made any radical changes) and that runs in a COG. zicog_cpm can then start 7 others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ah - thanks guys. So the 'main' spin program also uses a cog too? Hah, I guess that would explain why when I stopped the first cog the whole prop stopped running.
Hmm - I have been off to the obex and found a nifty driver that can do 4 serial lines in one cog. However it isn't quite what I need as it (apparently) only just fits and has 64 byte buffers and includes RTS and CTS lines. I don't use those (simple 3 wire RS232 connection Rx Tx and Gnd) but ideally I would like a 256 byte buffer (xmodem packets are 132 bytes) and only need two ports.
I have a feeling Kye might have written something but I'm struggling a little with the search on the forum and I seem to recall Kye doesn't have a website so it is a matter of finding the thread. [noparse][[/noparse]postedit - I sent Kye a PM] Or maybe there is another object out there?
Well Dr_A, if you are running out of COGs I will for sure forget any ideas of spreading ZiCog over multiple COGs instead of using overlays. Not that I was very seriously considering it anyway.
If you are thinking about adding I2C devices on the EEPROM pins that will require a COG or two.
This gets me thinking about what to do with MoCog for the 6809. Looks like using any more than 2 COGS for the emulation is would be a real no-no.
As always it's a shame to see a whole 32 bit processor being tied up for a keyboard.
The Prop is so frustrating sometimes...all that power but always limits throttling it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: For MoCog use the extra cogs. To get any speed with SRAM there must be NO latches. The simple solution is staring us in the face - use another prop for the I/O !! BTW, the prop is not frustrating - we are just trying to use it in ways it was not designed for
My VideoBlade pcb designed for standalone or plug-in with the RamBlade may be off to manufacture tomorrow··· Another 1.9"x1.2" footprint SMT pcb···Prop, eeprom, VGA, TV, 2xPS2 (on 1xPS2 or dual USB connectors), PropPlug connection, 12 I/Os (e.g. 2 for RamBlade serial, 2 can be Digilent RS232 PMOD connection, plus·8 more I/Os), 5V & 3V3 regulators. I will·do a microSD pcb to plug-in for·the VideoBlade for standalone use without the RamBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had a couple of free hours yesterday so I made the mistake of taking my own advice and running the EXZ80DOC.COM instruction et exerciser test on my TriBlade.
Well, 36 hours later the results are not very encouraging[noparse]:([/noparse] and a whole bunch of stuff I should have been doing instead is behind schedule...
What I ended up doing is modifying the test so that:
1) The test cases are rearranged into order of increasing execution time. Except...
2) All the test cases that cause a BREAK due to being unimplemented are at the end so it will bail out after having done as much as it can at the moment.
Here is the result:
ZiCog 1.0_rc_5.5b on the TriBladeProp v0.123_
Starting Hdisks...
A:A.DSK 148088 14
B:B.DSK 16952 14
C:C.DSK 33336 14
D:D.DSK 49720 14
E:E.DSK 66104 14
F:F.DSK 82488 14
G:G.DSK 98872 14
H:H.DSK 115256 14
R:ZIBOOT.COM <-bootcode 131640 14
Loading SRAM...
Starting Z80 emulation...
Passed, please wait...
64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi05, 2 HD, 30-Sep-2009)
SuperSUB V1.1
A>; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE
A>exz80doc
Z80 instruction exerciser
Undefined status bits NOT taken into account
ld hl,(nnnn)..................( 16) cycles OK
ld sp,(nnnn)..................( 16) cycles OK
ld (nnnn),hl..................( 16) cycles OK
ld (nnnn),sp..................( 16) cycles OK
ld (<ix,iy>+1),nn.............( 32) cycles OK
ld (<ix,iy>-1),nn.............( 32) cycles OK
ld <bc,de>,(nnnn).............( 32) cycles OK
ld <ix,iy>,(nnnn).............( 32) cycles OK
ld <ix,iy>,nnnn...............( 32) cycles OK
ld a,<(bc),(de)>..............( 44) cycles OK
ld a,(nnnn) / ld (nnnn),a.....( 44) cycles OK
ldd<r> (1)....................( 44) cycles OK
ldd<r> (2)....................( 44) cycles OK
ldi<r> (1)....................( 44) cycles OK
ldi<r> (2)....................( 44) cycles OK
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
ld (nnnn),<bc,de>.............( 64) cycles OK
ld (nnnn),<ix,iy>.............( 64) cycles OK
ld <bc,de,hl,sp>,nnnn.........( 64) cycles OK
ld (<ix,iy>+1),a..............( 64) cycles OK
ld (<ix,iy>-1),a..............( 64) cycles OK
ld (<bc,de>),a................( 96) cycles OK
ld a,(<ix,iy>+1)..............( 128) cycles OK
ld a,(<ix,iy>-1)..............( 128) cycles OK
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
<set,res> n,(<ix,iy>+1).......( 448) cycles ERROR **** crc expected:cc63f98a found:3d695930
<set,res> n,(<ix,iy>-1).......( 448) cycles ERROR **** crc expected:b2cdd674 found:43c776ce
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
ld <b,c,d,e>,(<ix,iy>-1)......( 512) cycles OK
ld (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
<inc,dec> bc..................( 1,536) cycles OK
<inc,dec> de..................( 1,536) cycles OK
<inc,dec> hl..................( 1,536) cycles OK
<inc,dec> ix..................( 1,536) cycles OK
<inc,dec> iy..................( 1,536) cycles OK
<inc,dec> sp..................( 1,536) cycles OK
bit n,(<ix,iy>+1).............( 2,048) cycles ERROR **** crc expected:a8ee0867 found:216e7b00
bit n,(<ix,iy>-1).............( 2,048) cycles ERROR **** crc expected:29c170d8 found:a04103bf
<inc,dec> a...................( 3,072) cycles OK
<inc,dec> b...................( 3,072) cycles OK
<inc,dec> c...................( 3,072) cycles OK
<inc,dec> d...................( 3,072) cycles OK
<inc,dec> e...................( 3,072) cycles OK
<inc,dec> h...................( 3,072) cycles OK
<inc,dec> l...................( 3,072) cycles OK
<inc,dec> (hl)................( 3,072) cycles OK
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
cpd<r>........................( 6,144) cycles ERROR **** crc expected:c8439345 found:e3bc468c
cpi<r>........................( 6,144) cycles ERROR **** crc expected:e66fa7d2 found:d6607fd7
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
neg...........................( 16,384) cycles OK
add hl,<bc,de,hl,sp>..........( 35,840) cycles OK
add ix,<bc,de,ix,sp>..........( 35,840) cycles OK
add iy,<bc,de,iy,sp>..........( 35,840) cycles OK
aluop a,nn....................( 45,056) cycles OK
bit n,<b,c,d,e,h,l,(hl),a>....( 49,152) cycles OK
<daa,cpl,scf,ccf>.............( 65,536) cycles ERROR **** crc expected:9b4ba675 found:c2e033f4
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a0 found:70201f28
aluop a,(<ix,iy>+1)...........(229,376) cycles OK
aluop a,(<ix,iy>-1)...........(229,376) cycles OK
aluop a,<b,c,d,e,h,l,(hl),a>..(753,664) cycles OK
shf/rot (<ix,iy>+1)...........( 416) cycles PC=253F AF=8082 BC=94F4 DE=DBF6 HL=FF3C IX=0102 IY=0102 SP=61D9
There are a further 11 tests after the one that you see bailing out there.
6 of those 11 deal with operations on HIGH or LOW halves of the IX,IY registers which as far as I know are not documented ops of the original Z80.
Now I've got my work cut out to identify exactly what the failing op codes are and fix them.
For sure the string I/O and string comparison ops are not done. Neither a whole set of bit test/set ops.
Attached is a zipm2.dsk image to use as a drive A: boot disk which contains the modified EXZ80DOC.COM.
Also attached is a ZIBOOT.COM in case mikdev is still looking for one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re cogs, there probably is scope to combine code together. The three cogs this might apply to would be keyboard, ram driver and sd driver. I might do some quick tests with these individually just to see how much free space is available in each. And/or use the standard 4 serial port driver and live with the 64 byte buffer. There probably is a way of moving bytes from the buffer in the cog to a buffer in hub somehow, perhaps by dropping the speed back a bit (38k is fine for me) and moving the bytes during the stop bits.
Re the Z80 exerciser, thanks ++ to heater for rearranging the order of the instructions. That makes it much easier to use as you can at least see it starting up and doing something rather than hanging. As for why some CRCs fail, heater, have you still got that N8VEM board I sent you? Maybe that could be useful in some way? I've used DDT very successfully to debug many 8080 programs but its Z80 equivalent ZDT never seemed to work quite right. I don't think the version I had went with the instructions I had.
Some of those Z80 instructions seem to be in groups, so I guess the first step might be to break them up into individual instructions. @heater, I can't open that disk image here at work, but does it contain the source code for the exerciser? And if so, which compiler does it use and is that on the disk too? Maybe we could share it out and each of us test a few instructions?
Comments
I have mused on the decoder and latch bits of Dracblade, they will fit int a XC9536XL ( LCD not implimented ) One spare pin and only 66% used innards, although I havent floorplanned it yet. "
Fascinating! That could save 4-5 chips.
I've got a new board on the way that is slightly different in that the 4 pins that control the SD card are contiguous (12-15) and the 4 pins for the 138 are also contiguous (8-11). Also I changed the 138 outputs slightly. The new board is on the way (also includes switchers for both 5V and 3V3 - I'm hooked on switchers!) and once I make a few code changes and get it working I can call this a finished design ready for its own thread. I've still got a few things to test eg:
* LCD display
* The second serial port
* TV out (with Cluso's intriguing suggestion of doing TV with one pin?)
* Double check the VGA resistors as they seem to be round the wrong way (they were copied from the PockeTerm schematic and are using PockeTerm code and the green looks ok)
* Bring out 4 header pins for I2C
A XC9536XL sounds intriguing. $1.07 from digikey which may well end up cheaper than the chips it replaces. I know absolutely nothing about these chips, especially the complexities of how you program them. Do you program them with serial, RS232, USB or via a special programmer or some other way?
At the most fundamental level, the CPLD has 12 inputs, and it has 19 outputs. 25 outputs if you include the LCD display. I see the chip has 34 I/O pins.
There may be scope to drive the LCD display differently - the 4 data nibble lines could be pins 0-3 on the prop, the rd/wr could be pin 4 on the prop, and the enable could be an inverted output from a 138. Then the display would ignore data lines unless it was selected. I need to look at the LCD specs again, but perhaps the 4th latch is not needed. Indeed it could have been done using the third latch but I wasn't confident driving a 5V LCD display using 3V3 logic levels so the main function of the 4th latch is as a level translator.
Perhaps the LCD display is not needed? They cost $16. Graphics LCD displays can display twice as many rows for the same price. Or for $33 you can get small TV screens (though I need to check the resolution looks ok). And then there is the I2C bus - if that comes out externally, you can always add I2C to parallel with one chip and drive a display that way.
Going back to testing Z80, I've been running the EXZ80DOC program but it is failing the checksum on the first set of tests, and in the middle are so many tests that it hangs on an overnight test, and I'm not sure if it is crashing or just taking several days to get there. Maybe I'll need to set the triblade going on a dedicated PC for comparison as this takes so long. I got this checksum error on the triblade on the first test:
and the Dracblade gives the same crc values.
How did other people go with the exerciser?
Cluso - where did we get to with the discussion about the floppy drive images? I'm thinking about making one drive (?drive F for Floppy) a floppy image, so it would be possible to import disk images straight from the SIMH. I can't recall whether there is the code working to work with unprocessed floppy disk images.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/21/2009 12:59:07 AM GMT
I think the 1-pin TV is in the OBEX. I should try it out (time??).
VGA resistors - check the Prop ProtoBoard circuit.
There is currently no code to use unprocessed floppy images although it is relatively simple. However, the code we are now using has no floppy support. There is an #ifdef to turn it back on but then its 8 floppies and 2 HD. Suggest we just reformat with VB or SIMH and post the files, or Xmodem them across.
re the CRCC bug, it is possibly because heater has not got all the flags correct for the Z80. You will need him to answer that.
Is your code ready for inclusion in a V1.0 release? I was not going to hold up the release for RamBlade as I'd like to get it out quickly before I get burried again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The reason I dislike smt (for prototyping and small runs) is that DIP chips can be recycled so easily from other projects. Also debugging is simpler if a chip has possibly been zapped.
Today got text on the 20x4 LCD display. It is still messy text as the display is just printing it rather than acting as a terminal that scrolls up 1 if on the last line, but I just have to translate some Z80 opcodes to spin. All good fun!
Re version 1.0 - my code is not ready yet as I'm going to be changing it soon when the new board arrives as the pins are different. There are also large parts of the code that are the same for the triblade and dracblade but not heaters original emulation, and I'm not sure how to do an #ifdef 'a or b', so the alternative is cut and paste large sections of code and duplicate them. So if you go ahead and release it I can take that and do a 'clean' revision of the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
www.leonheller.com/Geocities/xc9536.jpg
You are welcome to the artwork if you want to make one.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 3:57:24 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A 4-8 megabyte Propeller solution is quite easy if you have need/room and are willing to do a little work.
Speed will always be an issue for Propeller XMM regardless of the approach though.
BTW when I last looked the PLCC sockets had staggered 0.1" double row pins so you cannot use vero board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Absolutely correct. At the moment the only thing bst[noparse][[/noparse]c] excludes is unused spin methods. The latest -pre versions of bst will tell you if a global or local variable in a spin block is unreferenced, but it certainly does not touch them.
No guesswork is even performed on DAT blocks. Just too many ways to do funky tricks for the compiler to try and figure out what is going on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I got the LCD working! See attached photo. So output goes to the vga display, the LCD display and to the serial port and hence terminal program. You can use one or as many of these as you like (it has been very handy when debugging for instance to send the decimal value of bytes to one type of display and send the actual byte to another).
Attached, warts and all, is a zip of the files. It is a muddle and contains a few mildly frustrated comments about wierd bugs (eg why do 'if' statements in spin sometimes change the value of the variable they are testing if the variable is a global variable, but not if copied to a local variable?). But I've found solutions and it does all work.
Cluso, re your comments on the floppy disk images, yes, it is easy to do downloads via xmodem for one or two files, or copy a complete image over for bulk transfer of files.
In the last hour I've actually been using the board for useful things, and I must say that it is so much easier with all this disk space compared with the N8VEM and its single 448k drive. Now I can fit wordstar and a programming language all on one disk!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
The chip on that demo board is in a BGA package, it's tiny!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 8:09:55 AM GMT
Thinking of memory chips, there is most of the chip sitting there unused, and some time back Cluso had a demo working of CPM 3 or something similar that used banked memory. I think it was primarily designed for different 'users' on the same system. It could be something fun to do since one 'user' could be the local keyboard/vga, the second could be the first serial port to a terminal program, and the third 'user' could be via the other serial port to (say) a propeller PockeTerm.
I'm bursting at the moment with crazy ideas! eg - shift the sd card select from a dedicated prop pin over to the 138. That frees another pin. I'm coming to think that 'output' pins on a prop are easy, as you can always add latches etc (I've got 7 unused pins) and pwm out them for analog or digital. But 'input' pins are precious, especially if they are polling asynchronous data. This is the strength of the prop - the ability to poll a keyboard, a couple of serial ports and something else all at the same time. I'd like a spare pin to read some analog data. In particular, the analog data from an audio waveform and then see if it is possible to get that nifty bell modem code working as audio. Then via handheld radios. Then directly via radio. And/or, infrared and have the ability to detect the raw noisy RF input and do clever things like filter out the mains frequency at 50 or 60Hz via some filtering.
As you can tell, I'm now hopelessly hooked on the Propeller!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 8:28:07 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
My assumption that the LCD was some debug help was obviously wrong, and so the 9536 falls down on pin count. A 9572 in 84 pin guise would hold no advantage over a real prop in area. I was just looking for an excuse to put another small bit of learning onto another. I didn't know that you hated SMT so much either, you have seen my efforts, state of the art miniturization (pre 1970s). The thru hole sockets are expensive and double the area, also they do a mind bending pin-order-dance in the corners. It was Leon's artical that I based my experimental bd on, with Xilinx Mk3 JTAG parallel interface ( they publish cct ). I should turn the interface '126s into a CPLD project, just for the incestious irony.
The LHS is JTAG, middle is 9536/72 PLCC44 with PSU and clock options, RHS is just a few is and outs. The remote bd is fo PLCC84 9572s etc, there used to be a 95108 and a 95144 but they seem to have dissapeared, and the 72 is 5V only. This was destined for the Nascom rebuild.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I do like the idea of hybrids. Worth exploring further...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Amontec's Chameleon device (another one!) uses a Xilinx CoolRunner chip to emulate all sorts of JTAG interfaces, via adapter boards, by reprogramming it. They gave me one some years ago to try out on an ARM board I designed, and I've used it with Xilinx chips via a simple home-made adapter.
I remember someone in the press calling the Nascom the NASty COMputer.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/21/2009 2:56:35 PM GMT
I've been pondering some real world interface for the triblade and dracblade. While the prop can do analog I/O, both these boards have run out of pins (unless you add another prop of course) But there was mention on another thread recently about using the two lines to the EEPROM as an I2C bus.
Back in the olden days ADC and DAC was complicated and needed dual rail power supplies etc. Pondering a minimum circuit for an I2C ADC, it is VSS VCC, input, clock and data. 5 pins, and indeed such a chip does exist (indeed many do). $2 from Farnell with free shipping:
ww1.microchip.com/downloads/en/devicedoc/21732b.pdf 12 bits too.
It has a companion DAC for just over $2:
www.farnell.com/datasheets/37979.pdf
Is there a catch as it seems too simple given the I2C drivers are already in the obex.
And a question - would it be possible two add two ADC chips on the same bus, or would their addresses conflict? (and therefore would it maybe be better to get one with 4 or 8 inputs?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/22/2009 2:02:34 AM GMT
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
I might be missing one, but I've got
1 for the keyboard
1 for the first uart
1 for the zicog
2 for the vga driver
1 for the ram driver (same as cluso's tbp2)
1 for fsrwfemto (sd card).
Hmm - that makes 7 so I must be missing one.
I put in a little trace at the beginning
which returns a value of "2". The code in the uart object is
So I'm not sure if this is returning the actual cog number or the cog number plus 1
Is a cog running to do the bootup I2C to the eeprom by any chance?
I don't think any of these can be stopped. Help would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/22/2009 11:46:04 AM GMT
okay := cog := cognew(@entry, @rx_head) + 1
You are correct, cog returns the cog+1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Hmm - I have been off to the obex and found a nifty driver that can do 4 serial lines in one cog. However it isn't quite what I need as it (apparently) only just fits and has 64 byte buffers and includes RTS and CTS lines. I don't use those (simple 3 wire RS232 connection Rx Tx and Gnd) but ideally I would like a 256 byte buffer (xmodem packets are 132 bytes) and only need two ports.
I have a feeling Kye might have written something but I'm struggling a little with the search on the forum and I seem to recall Kye doesn't have a website so it is a matter of finding the thread. [noparse][[/noparse]postedit - I sent Kye a PM] Or maybe there is another object out there?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/22/2009 12:34:37 PM GMT
If you are thinking about adding I2C devices on the EEPROM pins that will require a COG or two.
This gets me thinking about what to do with MoCog for the 6809. Looks like using any more than 2 COGS for the emulation is would be a real no-no.
As always it's a shame to see a whole 32 bit processor being tied up for a keyboard.
The Prop is so frustrating sometimes...all that power but always limits throttling it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My VideoBlade pcb designed for standalone or plug-in with the RamBlade may be off to manufacture tomorrow·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 11/22/2009 1:31:41 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This morning I was musing upon a "Lego" brick way of stacking up projects. Your Sub Blades sound just like that. One "motherboard" and off we go.
Double checked the numbers, but still no chance of shuttled Bs (which is a B******)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Well, 36 hours later the results are not very encouraging[noparse]:([/noparse] and a whole bunch of stuff I should have been doing instead is behind schedule...
What I ended up doing is modifying the test so that:
1) The test cases are rearranged into order of increasing execution time. Except...
2) All the test cases that cause a BREAK due to being unimplemented are at the end so it will bail out after having done as much as it can at the moment.
Here is the result:
There are a further 11 tests after the one that you see bailing out there.
6 of those 11 deal with operations on HIGH or LOW halves of the IX,IY registers which as far as I know are not documented ops of the original Z80.
Now I've got my work cut out to identify exactly what the failing op codes are and fix them.
For sure the string I/O and string comparison ops are not done. Neither a whole set of bit test/set ops.
Attached is a zipm2.dsk image to use as a drive A: boot disk which contains the modified EXZ80DOC.COM.
Also attached is a ZIBOOT.COM in case mikdev is still looking for one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re the Z80 exerciser, thanks ++ to heater for rearranging the order of the instructions. That makes it much easier to use as you can at least see it starting up and doing something rather than hanging. As for why some CRCs fail, heater, have you still got that N8VEM board I sent you? Maybe that could be useful in some way? I've used DDT very successfully to debug many 8080 programs but its Z80 equivalent ZDT never seemed to work quite right. I don't think the version I had went with the instructions I had.
Some of those Z80 instructions seem to be in groups, so I guess the first step might be to break them up into individual instructions. @heater, I can't open that disk image here at work, but does it contain the source code for the exerciser? And if so, which compiler does it use and is that on the disk too? Maybe we could share it out and each of us test a few instructions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/22/2009 10:47:45 PM GMT