HX512 firmware for use with proto board and CPU emulators (untested)
AntoineDoinel
Posts: 312
To avoid cluttering the ZICOG thread I'm posting this here.
Basically what I'm trying, without very much knowledge of ABEL HDL or Lattice isp4000 in particular, is to hack the HX512 SRAM card firmware so it can be used for faster access by cpu emulators.
The problem with the original firmware is that it's optimized for fast sequential access on the whole memory, while random access require latching lower and upper address separately and only works on·lower 64KB area.
When an emulator need to access memory for data after an instruction fetch, the auto increment feature is no more useful because you have to load the counter again, disrupting the code flow sequentiality.
So here's my idea: if two 16-bit counters (program counter and data pointer) plus two 3-bit bank registers could be fitted in the CPLD, emulator access would benefit greatly from the· sequential access to code (only need to reload the program counter if code flow is altered, i.e. jumps and calls). Accessing data is performed using the other pointer (not slower than it is now).
The two bank registers would allow relatively fast and random access to the whole RAM space, and in perspective to emulate the way banking is done in CP/M 3 and MP/M.
The translation would go like this:
· logical·$0000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=0 a14=0 \
· logical·$4000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=0 a14=1 |- 48KB banked RAM area (8 banks)
· logical·$8000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=1 a14=0 /
· logical·$C000 -> physical [noparse][[/noparse]brb2..brb0][noparse][[/noparse]a15..a0]· with a15=1 a14=1 -- 16KB shared RAM and ROM (tipically points to upper bank brb=%111)
where bra and brb are the banking registers, a15..a0 is the address coming out of either the program counter or the data pointer.
The downside is that the pin currently used for reset is needed as the 3rd pin to specify the operation, and that pin is physically connected to RST in Hydra board while is freely connectable (and reusable) on proto... so this is mostly applicable to proto board.
Control pins specify the operation, function of clock strobe remain the same:
·%000 - load both bank registers from databus d5..d0
·%001 -·read one byte from pointed by·PC and post increment PC (fetch)
·%010 - write one byte to address pointer by DP and post increment DP
·%011 - read one byte from·address pointer by DP and post increment DP
·%100 - set PC low
·%101 - set PC high
·%110 - set DP low
·%111 - set DP high
The attached source is untested since I've yet to build a proper JTAG cable to reprogram the CPLD, it seems to compile and pass the fitter test in the ispLEVER tool anyway.
If somebody is familiar with ABEL, comments on the attached code are welcome
Basically what I'm trying, without very much knowledge of ABEL HDL or Lattice isp4000 in particular, is to hack the HX512 SRAM card firmware so it can be used for faster access by cpu emulators.
The problem with the original firmware is that it's optimized for fast sequential access on the whole memory, while random access require latching lower and upper address separately and only works on·lower 64KB area.
When an emulator need to access memory for data after an instruction fetch, the auto increment feature is no more useful because you have to load the counter again, disrupting the code flow sequentiality.
So here's my idea: if two 16-bit counters (program counter and data pointer) plus two 3-bit bank registers could be fitted in the CPLD, emulator access would benefit greatly from the· sequential access to code (only need to reload the program counter if code flow is altered, i.e. jumps and calls). Accessing data is performed using the other pointer (not slower than it is now).
The two bank registers would allow relatively fast and random access to the whole RAM space, and in perspective to emulate the way banking is done in CP/M 3 and MP/M.
The translation would go like this:
· logical·$0000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=0 a14=0 \
· logical·$4000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=0 a14=1 |- 48KB banked RAM area (8 banks)
· logical·$8000 -> physical [noparse][[/noparse]bra2..bra0][noparse][[/noparse]a15..a0]· with a15=1 a14=0 /
· logical·$C000 -> physical [noparse][[/noparse]brb2..brb0][noparse][[/noparse]a15..a0]· with a15=1 a14=1 -- 16KB shared RAM and ROM (tipically points to upper bank brb=%111)
where bra and brb are the banking registers, a15..a0 is the address coming out of either the program counter or the data pointer.
The downside is that the pin currently used for reset is needed as the 3rd pin to specify the operation, and that pin is physically connected to RST in Hydra board while is freely connectable (and reusable) on proto... so this is mostly applicable to proto board.
Control pins specify the operation, function of clock strobe remain the same:
·%000 - load both bank registers from databus d5..d0
·%001 -·read one byte from pointed by·PC and post increment PC (fetch)
·%010 - write one byte to address pointer by DP and post increment DP
·%011 - read one byte from·address pointer by DP and post increment DP
·%100 - set PC low
·%101 - set PC high
·%110 - set DP low
·%111 - set DP high
The attached source is untested since I've yet to build a proper JTAG cable to reprogram the CPLD, it seems to compile and pass the fitter test in the ispLEVER tool anyway.
If somebody is familiar with ABEL, comments on the attached code are welcome
Comments
I'm also investigating doing some mods to the HX512. See the thread here
Did you ever get your cable built and your firmware tested?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
By the way I'm hoping to have a Motorola 6809 emulator out "real soon now".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Largos - a nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
Unfortunately still no chance to test it, lately I've been really busy with my job (and a horde of brothers and friends·of the would-you-please-fix-my-PC kind
I've come to this 48/16 layout·by reading somewhere on the net that it was used in some machine as·MP/M banking scheme, I don't know if I've gone too far with wild speculation... anyway it served to familiarize a bit with Lattice tools, which indicate a really tight fit for the part (63 cells out of 64 if I recall correctly).
Yes, by setting BRA=BRB both Program Counter and Data Pointer would access one 64KB bank of countguous space out of 8 possible.
Also changing the bank bits·would be possible at any moment, not just after a card reset.
For graphics usage, I think that using a COG for fetching·line buffers and other(s) for rendering could work without much speed penalty apart from some bank command when crossing boundaries, after all the important thing is to get rid of the count-up system as used in the original firmware to reach higher mem.
Using the RAM for both CPU and GFX at the same time, well I don't know it's feasible at all... it starts to resemble "bad lines" of C64
Ciao
Alessandro
Don't know it it can be fixed, pre-fit is successful and·I guess we're just over·the edge.
Rolling back one version works, but I have to eat back what I said in last post, no more linear 64KB chunk access with the old one.
Have a look at the old one if you wish.
This one (dubbed v4) use a different access scheme:
0000h-7FFFh => 00000h-07FFFh => fixed 32KB segment at the bottom of SRAM
8000h-BFFFh =>····· xx000h······ => banked 16KB segment
C000h-FFFFh => 7C000h-7FFFFh => fixed 16KB segment at the top of SRAM
PC and DP counters are 14 bits each, and 5-bit bank register is shared.
Still useful for emulation IMHO, but not as much as the v5.
Sorry guys, bear with the poor newbie
Ciao
Alessandro
Post Edited (AntoineDoinel) : 5/25/2009 9:40:04 AM GMT
Edit: Attached modified design. Basically it takes the address generation out of the when/then/else and hard-wires it as mux.
Post Edited (kuroneko) : 5/25/2009 10:57:30 AM GMT
there should be·at least one person, epmoyer,·who already modified and reprogrammed the HX512 firmware ( see http://forums.parallax.com/showthread.php?p=656146·), so he sure has the cable built... if he's not too busy playing guitar maybe he could test this one too·
His·solution it's also interesting, and·compatible with the original firmware. XMM for that could be faster and relatively effortless.
@RossH
I don't know which solution·is better match for compiler output.
I guess two counter registers are·useful, but what about·the·48/16 KB split map?
It could be changed to 32/32 without problems.
Ciao
Alessandro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
I PM'd him to describe the download cable to reprogram the HX512 firmware. This would enable me to purchase the HX512 card and reprogram the CPLD to randomly access the entire card.
Am I missing something in my assumptions?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Yesterday we had no solutions - today we have three! I'm still in the process of acquiring a suitable cable, so I can't test any of them yet. I may offer support for one or the other of them in the next version of Catalina. At the moment I'm busy finishing of the porting of the C89 library in preparation for the first non-beta release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Andre·made his own modifications to the original schematics, simplifying it down to a 74xx126·IC and some pullup resistors.
It also can be bought already made from Lattice for $65 for the parallel vesion, and $149 USB version
But what really scares me it's heater talking about 6809... you know how it goes: one starts·smoking·simple·6800's, then he never have enough and·turn to 6809's thru the nose... by then you're addicted, and the sad story ends with a 6309 stuck in the arm
Ciao
Alessandro
My equipment is at my office so I'll have to take a look tomorrow when I'm over there. As I recall, I used a standard Lattice CPLD cable; which I had around from using Lattice in other projects for my "real job". I believe the HX512's programming header was designed with a pinout to accept the standard cable. The cable I have is a parallel port adapter, but I think lattice makes and sells USB attached versions as well. Also, I recall that Lattice published a datasheet fully describing the construciton of the cable I have (the parallel port version); I'll poke around and see if I can find it.
Looking back at my old thread it seems like it just petered out. I was apparently off trying to add support for the DEFA18, DEFA17, DEFA16 bits, and then either I couldn't fit them or I got distracted by other projects. I'll go poke around and see if I can refresh my memory.
Ross; I've been very intrigued by Catalina but haven't done any work with it yet. Kudos for making it happen!
I've used Lattice parts for a long time so I've got a lot of familiarity with the architecture and the toolset. On a recent project with a very similar Lattice family part (about 2 years ago), I needed to be able to reprogram a Lattice part in the field. It turned out that Lattice had published an open-source C engine which could process the device binary and load the part via the JTAG interface. I was able to port their C code to the Motorola ColdFire and load the device from code. I still have that software. If one were clever, I can imagine it would be possible to build a simple cable (wires and connector(s) only, no components) that would connect the Hydra protoboard (can't remember what it's really called, but that blank-ish prototyping board that came with the Hydra and plugs into the expansion card slot) to the JTAGinterface on the HX512 (which would just be sitting on the table, not plugged into the expansion port) and program the HX512's Lattice part using a port of Lattice's C code running under Catalina. If such a solution were achievable, it would provide a relatively easy path for other HX512 users to re-image their lattice devices.
By the way, I was just looking through the HX512 manual, and Appendix C contains schematics for the Lattice programming cable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
There is a datasheet for Lattice's programming cables on their site here: www.latticesemi.com/lit/docs/devtools/dlcable.pdf. The datasheet does not tell you how to build the cable (which has an internal line driver), so Appendix C of the HX512 manual is probably the best reference for doing so.
Regarding "on board" programming....
Lattice's software for programming devices via embedded processors is called "ispVM Embedded". The main page on ispVM Embedded is here: www.latticesemi.com/products/designsoftware/ispvmsystem/ispvmembedded.cfm. It looks like you have to sign in and download the ispVM package to get it.
I have versions of the files from back in Sep of 2006. I had gotten it working on a Motorola ColdFire, but I was running under uClinux so I had a file system up and running. It looks like ispVM embedded wants to process a file, so it may take some glue work to shove the pld file into memory and feed it to their code a line at a time or whatever. As I recall, the primary effort in porting was to modify their hardware.c file so that the varioius routines that wiggle or read the JTAG lines got glued up to your particular hardware.
It's probably a fair bit of work to get it all wrapped up with a bow and ported to work on a prop under Catalina, but I imagine it's possible.
Regarding my old HX512 image
The image I posted to http://forums.parallax.com/showthread.php?p=656146 was done and will work fine for extending Catalina into the full memory space. I had been thinking to update it with additional functionality (the DEFA18, DEFA17, DEFA16 bits discussed in the thread), but that feature isn't actually all that useful when you think about it. The only benefit in allowing you to define the initialization of the upper bits it to try to gain a speed boost in the case where two different "processes" are accessing different pages. In that case one of them always has to write the upper bits anyway, and the other would not, but the speed savings are small since both processes would be likely to write the page address once and then do a long burst anyway, so saving one extra address cycle on one process isn't that useful, so I'm calling it "done".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
I've just received the parts for building my cable (ala Appendix C). If my aged eyes and infirm hands can still manage a soldering iron I should be able to try out your modifications in the next few days.
I'll report how it goes.
Ross.
P.S. I'm not going to worry about "onboard" programming at this stage. That would be really cute, but is not necessary for me - I'll leave that one to some other lunatic to attempt!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I found this programmer
www.sparkfun.com/commerce/product_info.php?products_id=8705
is it possible to adapt it to program the HX512 card?
Thanks
Gianni