PDA

View Full Version : HX512 firmware for use with proto board and CPU emulators (untested)



AntoineDoinel
04-04-2009, 03:22 AM
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 [bra2..bra0][a15..a0]· with a15=0 a14=0 \
· logical·$4000 -> physical [bra2..bra0][a15..a0]· with a15=0 a14=1 |- 48KB banked RAM area (8 banks)
· logical·$8000 -> physical [bra2..bra0][a15..a0]· with a15=1 a14=0 /
· logical·$C000 -> physical [brb2..brb0][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 http://forums.parallax.com/images/smilies/jumpin.gif

RossH
05-24-2009, 08:10 PM
HI Antoine,

I'm also investigating doing some mods to the HX512. See the thread here (http://forums.parallax.com/showthread.php?p=809801)

Did you ever get your cable built and your firmware tested?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Mike Huselton
05-24-2009, 08:42 PM
Guys, this would be wonderful. Thank you so much for even considering this...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

heater
05-24-2009, 10:12 PM
Hey this is great. Sadly I missed this when it was first posted.

By the way I'm hoping to have a Motorola 6809 emulator out "real soon now".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Bill Henning
05-24-2009, 10:39 PM
Looks great, more useful than the default CPLD configuration, however unless I mis-understood what you wrote, it imposes a bit of a limitation on accessing the 512K of ram - namely unless BRA = BRB, it is not possible to address a contiguous 64K chunk of memory for use as a frame buffer. It will be great for running banked memory CPM/MPM though http://forums.parallax.com/images/smilies/smile.gif


AntoineDoinel said...
To avoid cluttering the ZICOG thread I'm posting this here.
The translation would go like this:

logical $0000 -> physical [bra2..bra0][a15..a0] with a15=0 a14=0 \
logical $4000 -> physical [bra2..bra0][a15..a0] with a15=0 a14=1 |- 48KB banked RAM area (8 banks)
logical $8000 -> physical [bra2..bra0][a15..a0] with a15=1 a14=0 /
logical $C000 -> physical [brb2..brb0][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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Largos (http://www.mikronauts.com) - a nano operating system for the Propeller
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

mikediv
05-25-2009, 06:00 AM
heater that would be awesome I have been waiting for a 6800/09 emulator I have an old heath kit 3400 with a 6800 chip I wanted to try and interface it to the prop , I only have the basic trainer with 512 bytes of ram it has a solderless breadboard and some led displays on it I thought it would make an awesome trainer for the prop

AntoineDoinel
05-25-2009, 07:19 AM
Hello

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 http://forums.parallax.com/images/smilies/lol.gif)
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).


Bill Henning said...
Looks great, more useful than the default CPLD configuration, however unless I mis-understood what you wrote, it imposes a bit of a limitation on accessing the 512K of ram - namely unless BRA = BRB, it is not possible to address a contiguous 64K chunk of memory for use as a frame buffer. It will be great for running banked memory CPM/MPM though http://forums.parallax.com/images/smilies/smile.gif




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 http://forums.parallax.com/images/smilies/tongue.gif·but I don't think it's fast enough (there's the advantage of two separate pointers, but still one of the two should be reloaded at each scanline).

Ciao
Alessandro

kuroneko
05-25-2009, 09:44 AM
AntoineDoinel said...
... 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).

Out of interest, how did you manage to fit this design? I use the LC4064V-75T100I part as suggested in the HX512 documentation and your (unmodified) design from the initial post, but partitioning fails.

AntoineDoinel
05-25-2009, 04:32 PM
Hello

kuroneko said...

Out of interest, how did you manage to fit this design? I use the LC4064V-75T100I part as suggested in the HX512 documentation and your (unmodified) design from the initial post, but partitioning fails.
I've checked again, you're right... strange, I was more than sure to have seen·it compiling back then when I made the first post...·or it's just me sniffing the wrong brand of glue http://forums.parallax.com/images/smilies/nono.gif

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 http://forums.parallax.com/images/smilies/blush.gif

Ciao
Alessandro


Post Edited (AntoineDoinel) : 5/25/2009 9:40:04 AM GMT

kuroneko
05-25-2009, 04:49 PM
AntoineDoinel said...
I've checked again, you're right... strange, I was more than sure to have seen it compiling back then when I made the first post... or it's just me sniffing the wrong brand of glue http://forums.parallax.com/images/smilies/nono.gif

Don't know it it can be fixed, pre-fit is successful and I guess we're just over the edge.

No problem, I played around with the design and by re-arranging some bits I can make it fit.

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

AntoineDoinel
05-25-2009, 08:39 PM
kuroneko said...


No problem, I played around with the design and by re-arranging some bits I can make it fit.

Edit: Attached modified design. Basically it takes the address generation out of the when/then/else and hard-wires it as mux.
That's great, thanks!

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·http://forums.parallax.com/images/smilies/smilewinkgrin.gif

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

Mike Huselton
05-25-2009, 09:24 PM
Thanks for the link to epmoyer's thread. This volatile mixture is getting to the boiling point http://forums.parallax.com/images/smilies/yeah.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Mike Huselton
05-25-2009, 10:01 PM
I did not realize that epmoyer had come extremely close to solving the 512k RAM problem for the Parallax memory card.
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

RossH
05-26-2009, 04:16 AM
Fantastic

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 (http://forums.parallax.com/showthread.php?p=795326)

AntoineDoinel
05-26-2009, 05:20 AM
James Michael Huselton said...
I did not realize that epmoyer had come extremely close to solving the 512k RAM problem for the Parallax memory card.
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?
James, how to make the cable is shown in the HX512 documentation, you can download the manual and have a look before buying the card.
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 http://forums.parallax.com/images/smilies/smhair.gif·SCAREY PRICES

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 http://forums.parallax.com/images/smilies/lol.gif

Ciao
Alessandro

epmoyer
05-26-2009, 05:25 AM
I had missed this thread before brought it to my attention. Hey there everybody!

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

Mike Huselton
05-26-2009, 05:36 AM
What a difference a day makes...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

epmoyer
05-27-2009, 07:52 AM
The cable I have is a Lattice HW7265-DL3A, which appears to be an earlier version of the HW-DLN-3C (the version they sell today).

There is a datasheet for Lattice's programming cables on their site here: www.latticesemi.com/lit/docs/devtools/dlcable.pdf (http://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 (http://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

RossH
05-27-2009, 08:01 AM
@epmoyer,

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 (http://forums.parallax.com/showthread.php?p=795326)

jazzed
05-27-2009, 10:10 AM
It's actually not that hard Ross ... we used to do it all the time in my switch/router days for remote updates. Beats the heck out of recalling boards from development sites or letting too many software types get VCC and GND crossed. But our products were not resource limited (except for taking 5+ hours to build an O/S after updating from the repository .... arrg).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Giemme
05-27-2009, 01:54 PM
Hi

I found this programmer

www.sparkfun.com/commerce/product_info.php?products_id=8705 (http://www.sparkfun.com/commerce/product_info.php?products_id=8705)

is it possible to adapt it to program the HX512 card?

Thanks

Gianni