Re: [hatari-devel] OT: My dream about Hatari

[ Thread Index | Date Index | More Archives ]


I'm happy to share it anytime :) It's just the Atari coder would need to understand that right now it's really tailored to my needs what might be pain for others. For example, I'm totally satisfied with the fact I'm writing new m68k parts in 100% C code (for controlling DSP etc), what is not usual thing on Atari (else it wouldn't be possible to debug on PC, of course).

So if you think it can help you, drop me a line.

On Tue, Jul 16, 2013 at 11:17 PM, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
This is great. I hope you can reach a point where you are happy to share this work with other Atari coders, regardless of whether it joins with Hatari or not :) the idea itself is really good (DSP emulator/debugger as one of a series of abstract project components) and it would be a shame for others to have to reinvent that!

I also spent a significant amount of time on the 'how' questions instead of the more fun side (i.e. making things) and the DSP debugging aspect remains difficult in some cases. It can never be made 'too easy' so anything which helps here is good news for me :)


On 16 July 2013 13:21, Miro Kropáček <miro.kropacek@xxxxxxxxx> wrote:
Hi guys,

sorry for the poetic subject but basically, it's true :) It's been some time when I had realized that if I want to code something serious (like an "Amiga style" demo), there's no way I can do it in 100% assembler with Devpac+qdsp+dspdebug threesome, i.e. that I need to organize structures in C(++), make it possible to debug in gdb (ideally on host) etc...

After long, long, long time of thinking, trying different approaches (like having Aranym running with ssh daemon which would execute qdsp and gdb :)), some lucky coincidences (Sqward's asm56k, Frank's vasm, Vincent's gcc) I've ended up with following:

- user code (demo + demolib) written in C with optimized parts in m68k asm; compilable for both host (asm routines replaced by C ones) and target
- simple emulator of screen and timers (Qt framework + OpenGL); m68k target uses the real ones, of course
- everything cross compilable, everything automated within Qt Creator (qmake), press F5 and the demo runs
- DSP emulator

(just to give you overview)

Now, naturally, the most interesting part was how to debug DSP programs without a DSP debugger (and without the DSP in the first place). My hopes were always in Hatari but it seems you guys focus more on reverse engineering features (and I don't blame you) than actually making life easier for living developers... so I had to come up with something. And I did, I've stolen your code :)

To be precise, I've taken the dsp decoder/disassembler, added two threads, some thread sync (emulating CPU <-> DSP communication), wrapped it into my Atari functions (so the demo code doesn't see any difference) and (here it comes) made a nice debugger for it!

The result can be seen here:

What do you see is 100% Intel powered Atari 030+DSP code, with debugger on both CPU (gdb/Qt Creator) and DSP (mine) side, synced, interruptible, i.e. everything you would expect from debugging two threads.

And why I am writing this... because after I figured it out (what to do), it took me only two weeks to take, change, use and extend Hatari DSP code!

So this is my last appeal to you, please implement a debugger into Hatari, a real debugger with stepping, changing values (regs, memory), UI (mainly UI ;), automatic symbol names (it's not there yet but I plan to import them from .LOD files, it's super easy) ... it really takes only two weeks and it would help me a lot (because my debugger has several limitations of course, no interrupts for example) and I'm sure not only me.

Sorry for such a long post but I just wanted to show you that something which might seems as a b***h work can be actually pretty simple to do.

MiKRO / Mystic Bytes

MiKRO / Mystic Bytes

Mail converted by MHonArc 2.6.19+