bob_er

Two questions: 1. Which C++ standard does your compiler support? 2. Do you have any chance to use GCC instead of OW?

Would be nice to know, how many guys have any kind of HDD (SH*, (ultra)satan, etc...).

Please add for instance 'nop' inside the DLI. If that will still crash - check your memory/linker config. Maybe there is something wrong? If that will pass - add next 'nop' just to check. Next step is to replace two 'nop's with one 'inc zp', etc... Do many small steps. That may help... (i hope ).

I'm not sure about cc65 (never used that) but first thing to check for me is branch correctness. Did you check jump value of 'bne'?

@RevEng Thanks a lot for the link. btw: note, that PDF links don't work. Fortunately speech spec I can download directly from vendor's homepage and available zips have examples :).

Where I can find documentation about flash memory protocol? How I can select/read/write pages? I want to use the AtariVox with XE series.

Currently only on my HDD. Could you send e-mail to me: bob_er (at) interia (dot) pl ? edit: main problem is because I have open frames and I want to read data from disk. That works with UltraSatan and Hatari (used by me for ST dev&tests). Unfortunately that combination doesn't work on FDD. This is main issue for me right now. Additionally, I've got some feedback, so I'm working on all fixes right now. I want to make version 1.2 as really final .

Story is a bit more complicated . Indeed, I've touched Timer C and few more interrupts. Still working on this. btw: is there any volunteer to (re)write the converter tool (can be written in any existing language on any existing platform)?

Hi Guys, I'm the coder of INR. Thanks for you comments . Currently I'm working on issue with TOS 2.06. As far as I know the game doesn't work on TT and Falcon as well. But 2.06 has higher priority for me. My own machine has 1.62. I've tried on hatari with 2.06 and it works . The game was written in pure ASM using VASM just for fun. I can make code public when code will be stable/final. I think it's possible to make engine more generic to support other scenarios. Things to be fixed for that are: 1. Connect chapters and pictures. Now I have an array in the code, should be exported to scenario file. 2. Connections between chapters. Similar to 1st point - now I have a second array. Should be exported to file as well. 3. Text converter should be probably rewritten. I've used tool written for C64 by JAD (thanks!), and modified it a bit to support ST features/customization. Because that tool was written in PHP (which is quite far on my list of favourite languages), my changes weren't nice.

If you know/like/understand polish, and you know/like/understand C and LISP, you can port this version to your system: https://www.jfedor.org/pfedor/hobbit.html As C/LISP are higher level languages than assembler, your task may be even simpler.

So, consider to copy ROM in some parts. To do this you will need additional routine for turning ROM on. No, 'system_off' should be part of your code. To FFFE you should put 'NMI' label (from code provided at atariki). During turning ROM off you must avoid any interrupts (NMI and IRQ as well). That's why I'm waiting for new value in $14. Memory at $14 is a part of system clock, changed each VBL. lda $14 - load current value of counter to Accumulator cmp $14 - compare Accumulator with current value of memory. x beq *-2 - if value is the same, compare again. That value is changed only by VBL interrupt routine, so this condition will be false just after VBL interrupt. Now you have >30k cycles to change NMI vector. So, in summary, you can resolve your issue this way: 1. Copy part of ROM to RAM. 2. Turn ROM off. 3. Copy data from 1 to final destination inside RAM under ROM. 4. Turn ROM on. 5. Jump to 1 until all done.

In case you just need more space for your data - it sounds like you don't need ROM copy at all (or at least this is my understanding). If so here you can find some details about switching ROM off: http://atariki.krap.pl/index.php/Programowanie:_Jak_wy%C5%82%C4%85czy%C4%87_ROM_systemu. Site is in polish, so please use your favourite translator (but at least code is understandable). Before call 'system_off' please synchronise with VBLANK using this code: lda $14 cmp $14 beq *-2 jsr system_off This is to be sure, that you don't get any NMI interrupt in the middle of switching off routine. After that you have RAM available up to $CFFF and $D800-$FFF9.

@jacubus: do you really need copy of ROM in RAM memory? What is your use-case? Here you can find some details about switching ROM off: http://atariage.com/forums/topic/209369-display-lists-and-double-buffering/?p=2705155 There is another thread about uploading data under ROM (and to EXT memory): http://atariage.com/forums/topic/212907-possible-to-load-to-high-memory-d800-from-xex/

Hi, Heh, I have similar project on my hdd. Unfortunately, it isn't finished. Nice features, that I have and you not are (as I see): - detect reading from unitililized memory (be carefull with hardware registers), - detect executing from unitialized memory - advanced breakpoints (memory1=x, memory2=y, memory3>z and PC=xxx), - call VBL each around 30000 cycles (to make some vbl clocks working).

Hi, 1. I'm working under Linux with Geany (as editor) and my own buggy assembler (similar to Mads but much simpler). 2. I don't think that there is any ready-to-use game engine. No such resources on a8. Graphics routines should be fit to your requirements (colors, modes, sprites, layout, etc...). Joystick is very easy - just read proper register. Sound is supported by tracker (msx player). 3. For sprites - I created own conversion tools from PC's .TGA format (created by modern paint stuff). Sound - there are various tools. On windows is Raster Music Tracker. In my soft music is composed on A8 using Theta Music Composer. 4. IMHO - it's hard to say. All final sources are optimized - code can be hard to read. Here you have some of them: http://sources.pigwa.net/?page=3