Motorola 6809: Halt vs. Busreq

[thingsis]

Hi,
I am working on a design for a 6809 SBC. For this I would like to program the EEPROM in system. To do this I need to stop the Processor and steal the bus. Now when using DMA, I would only have 15 cycles after which the Processor takes control of the buses again to do some refreshing. This seems difficult to deal with. Is it an alternative to use halt instead of Busreq? It seems like this stops the processor for as long as i want... But where is the difference then? Why is there DMA at all then?
Can't seem to figure this out. Maybe somebody has the answer.
Regards,
Henrik

[Lightages]

Wow, 6809! It has been decades since I worked with those. I wish I could remember. When I moved to Chile I don't think I bothered bringing the data book for it with me.

[Dave Turner]

http://www.classiccmp.org/dunfield/r/6809prog.pdf

If you are working with interrupts that are time dependent then Halt is not a good idea as ints are not recognized.

If I remember correctly there was a DMA chip that interfaced with the 6809 that took care of the details in the most efficient manner.

[thingsis]

Thanks guys,

Dave, if I understand you correctly though it would be totally okay to use halt for my purpose. After I reprogrammed the EEPROM I would have to reset the processor anyway as the program isn't the same anymore. I know there is a DMA chip for this processor - just would like to keep this simple.

Thanks again!

[thingsis]

Packaged and brand new - they found some in the basement...

[Dave Turner]

thingsis-  from the limited information available - yes. My gut says to look for a more elegant solution, though without knowing what you're attempting to achieve further speculation is pointless.

[chickenHeadKnob]

The most straight forward solution is to relax the 'in system' requirement. Solder a socket, a zif one if you will be programming often, unless you want to make life difficult for yourself. If you have a jedec socket anywhere onboard then a RAM/ROM emulator becomes an option for simulating in circuit programming convenience.

[SeanB]

If you are going to reset the CPU anyway simply reset it and hold it in reset during the reflashing, then release reset and it will run again. Reset tristates the buses anyway along with the control lines.

[Dave Turner]

Any of the suggestions made would work it depends on what's best for you. Consider also whether any dynamic memory needs to be maintained. If not, as I suspect, then it's probably not a problem. You just need to check whether the memory controller (if present)
also attempts to grab the bus.

[Pjotr]

The most straight forward solution is to relax the 'in system' requirement. Solder a socket, a zif one if you will be programming often, unless you want to make life difficult for yourself. If you have a jedec socket anywhere onboard then a RAM/ROM emulator becomes an option for simulating in circuit programming convenience.

Indeed. In those 6809 days I hooked up a small monitor EPROM and static RAM. During development the code was loaded in RAM and ran afterwards from RAM. And after all debugging was done the final code was blown into (E)PROM.

[thingsis]

Thanks for all the answers!
Just to clarify what i am trying to do. Basically I want to reprogram the Prom often. And because of that am looking for a way to not have to take it out all the time. Tristating the bus would do. The CPU does not need to run while I am doing this. Of course a solution where the code is copied to ram while developing would be fine - but sounds more complicated. Shouldn't it be totally enough to halt the CPU which tristates the bus and reset it after that? The only reason why I don't want to hold reset for as long as I am programming is that I heard you can damage the CPU whith doing that. Not sure if it is true...
Thanks again!

[Pjotr]

It is too long ago to remember how that worked. The reset was indeed a bit tricky if misused. It didn't kept the address bus tri-stated if I remember well. Mostly, on a 6809 SBC you had a serial interface at hand and a monitor rom was the usual way for SW development. You just plugged a piggyback board in place of the eprom with the monitor rom (about 1K code), ram and suitable address decoder. The most luxury way was was to use an ICE, but it was quite expensive those days.

Nowadays an eeprom is the most logical part for the rom. But for that you need to make board provisions imho to program it on-board.

[robgambrill]

On my old Radio Shack Color Computer (around 1983), I installed a switch that pulled the pin (HALT) low and mounted it next to my keyboard. It stopped program execution and allowed me to pause video games that didn't have that feature.

 If you used HALT, the program would pick up at the next address in the program counter when it went high, so you would have to pull reset low during the HALT (it gets latched). That way execution would jump to your newly installed code's startup vector when you left the HALT-ed state.

"While HALTED the MPU will not respond to real time requests (FIRQ,IRQ), although DMA/BREQ will always be accepted and NMI or RESET will be latched for later response."   The MC6809 Cookbook, Carl D. Warren, 1981

 The 6809(E) was my favorite 8 bit MCU, kinda neat to hear you are playing with them. I remember them as being very easy to develop with. If you needed more I/O pins, you just mapped another 6821 PIA into memory someplace.

 I know OpenCores has some code to implement the 6809 on an FPGA, but I am not sure why you would (other than as a cool retro-computing hack).