Tom
-
Content Count
446 -
Joined
-
Last visited
Posts posted by Tom
-
-
Well, I managed to change the graphics for the walking smurf animation in the disassembly, reassembling worked fine. If you posted an actual modified source code snippet that actually breaks the binary (for you), people might be able to help you.
-
I can't seem to reproduce it.
-
Hm, could you also post the changes you made that break the binary ?
-
Could be a problem with the cartridge type of the particular game you're trying to hack.
Maybe you cuold post the original rom image and an (unmodified) disassembly of the game you're trying to hack.
-
Hello,
I think there were several people working on trackers for Paul Slocum's Music Kit 2. Did any of these projects ever reach a state where it was usable ?
Cheers
Thomas
-
... way too much reading..Then better stop thinking about writing software for...well....any platform. Now.
(Was going to say you should read Andrew's tutorials, but that would involve...well...reading)
-
Hex Editors
in Hacks
Sorry, you're doing obviously something wrong, but I really don't know what it could be (the command I posted above is correct)
You don't need to put files in specific directories, but you must either pass the full path to the input file to dd, or you change to the directory the input file is in and only pass the file's name, without path information.
Iirc Cygwin also doesn't treat filenames case sensitive (Unix systems do so), so it shouldn't matter wether you pass "X.FOO" or "x.FOo" for a filename.
-
Hex Editors
in Hacks
downloaded it and used cygwin and I keep getiing this error message and I don't know why:
dd: opening '8kfile.bin' : No such file or directory
Any idea's? Do I need to use a specfic directory? I tried copying my 8kfile.bin into the cygwin working directory but no go.
You did use the correct filenames, right ? "8krom.bin", "bank0.bin" and "bank1.bin" in my first post were of course only placeholders. You have to substitute them with the real filenames you want to use. If that isn't the problem, post the whole command line you're using.
-
Hex Editors
in Hacks
A standard Unix utility. Everybody running Windows should have a Cygwin or GnuWin32 installation.
-
Hex Editors
in Hacks
Why a hex editor ? All you need is dd.
dd if=8krom.bin of=bank0.bin count=4096 bs=1 dd if=8krom.bin of=bank1.bin count=4096 bs=1 skip=4096
Simple and powerful.
-
Would our "version" of it take our brand of Basic and produce CV assembly code, which would then be handled by a regular Z80A assembly compiler?Would be a good idea. There are several very good open source Z80 assemblers available, so why bother with rolling your own machine code generation backend.
-
-
Occasionally I wonder why people bother to program on the real thing if they could be conveniently crossdeveloping on their PC/Mac/Whatever.
-
This document contains a BIOS listing (original, not a commented disassembly ?):
http://www.geocities.com/newcoleco/cv-coding-guide.zip
Apparently the BIOS contains among other things sprite multiplexing routines.
-
Philipp,
I think you have some small errors in your crt0.s. I don't think the EI/RETI sequence is correct for RST 8 through 30. The RST instructions are basically calls with an implicit address (0008h, 0010h, 0018h, 0020h, 0028h, 0030h). The BIOS has at these locations JP instructions to the cartridge header, and I think instead of EI/RETI you should put a RET instruction in there.
.dw start ; where to start execution of program. ei ; RST 0x08 reti ei ; RST 0x10 reti ei ; RST 0x18 reti ei ; RST 0x20 reti ei ; RST 0x28 reti ei ; RST 0x30 reti ei ; RST 0x38 - spinner interrupt reti jp nmi ; NMI nop
Should become
.dw start ; where to start execution of program. ret ; RST 0x08 nop nop ret ; RST 0x10 nop nop ret ; RST 0x18 nop nop ret ; RST 0x20 nop nop ret ; RST 0x28 nop nop ret ; RST 0x30 nop nop ei ; RST 0x38 - spinner interrupt reti jp nmi ; NMI nop
-
Ok, I found a BIOS disassembly. They point to buffers in RAM which some BIOS functions use. If you don't call those particular BIOS functions, the pointers can contain *any* value.
(The whole point in this seems to be to let the programmer have control over where these buffers are placed, since they can be fairly large. You could probably even overlay some them.)
-
Can anybody explain me, what the first four pointers (right after the cartridge identification word) in the cartridge header are good for ? Are these used by BIOS functions ? Is it safe to simply set them to 0 ?
-
Thank you. What's not entirely clear to me - is the thingy GPL'd ?
-
I have written a colecovision library and tools for use with sdcc. The game "Schlange CV" I posted about is written using that.Could you post the source ? Or at least compiler/linker command lines, startupcode/linker script ?
-
It's fairly easy to write a program for the Atari 7800 that supports PAL *and* NTSC (autodetecting the console type). Converting existing games might be more difficult. Basically to convert an NTSC game to PAL you'd have to insert additional empty lines into the display list. If there's not enough RAM left for that or you have to move stuff around in RAM to make space, then things will get really amusing
-
From reading these books, I know that BASIC is being translated into machine language by the computer so it can perform the tasks you program from BASIC(sorry if this is ignorant - I'm a newbie to this!!). So, I wonder - is there a source that will let me know how the computer translates the BASIC commands?
For instance, if I type in plot or print from BASIC - what set of commands does the computer change that into ?
That's not how Atari BASIC works. BASIC is not directly translated into assembly code, it's interpreted. The BASIC interpreter steps through the program, looks at the commands and calls assembly routines that perform the commands.
The BASIC code is only translated into a form that is simpler to read by the BASIC interpreter. This is done during *editing*. If you type in PRINT, what is actually stored in the program being edited is a byte with the value 20h. But this is not a 6502 opcode, it's only a token that tells the BASIC interpreter to call the routine that performs the PRINT command when the program is executed.
Here's a description of the Atari BASIC file format :http://www2.asw.cz/~kubecj/afmtbas.htm
It doesn't show which routines actually get called for the different BASIC commands. You'd need a BASIC/BIOS disassembly for that.
-
This is information I got from Al a while ago about EF bankswitching:
The bankswitching uses "hot spots" like F8, F4, and F6 bankswitching. There are 16 4K banks - hotspots for the 64K version were defined by Paul Slocum (whom we designed this board for originally):1FE0 => BANK0
1FE1 => BANK1
1FE2 => BANK2
1FE3 => BANK3
1FE4 => BANK4
1FE5 => BANK5
1FE6 => BANK6
1FE7 => BANK7
1FE8 => BANK8
1FE9 => BANK9
1FEA => BANK10
1FEB => BANK11
1FEC => BANK12
1FED => BANK13
1FEE => BANK14
1FEF => BANK15
-
I had been thinking about doing some sort of bankswitching, but I wasn't sure of the best way to do it. It looks like you've found an effective way of keeping the banks separate.It might have made sense to use a more advanced code generator than DASM in the first place (ca65/ld65 come to mind). But what do I care, I don't use bB, I just watch its progress when I'm bored enough at work
-
DASM can assemble code out of order. It just can't do so for raw binaries (the -f3 switch). As a workaround which neither involves modifying DASM (you don't want to do that, believe me) nor modifying bBasic you could try using RAS mode (the -f2 switch).
From the DASM manual:
2 RAS (Random Access Segment) The output file contains one or more hunks. Each hunk consists of a 2 byte origin (LSB,MSB), 2 byte length (LSB,MSB), and that number of data bytes. The hunks occur in the same order as initialized segments in the assembly. There are no restrictions to segment ordering (i.e. reverse indexed ORG statements are allowed). The next hunk begins after the previous hunk's data, until the end of the file.
You would have to write a small tool to remove the hunk headers and convert everything back into a raw rom image. This is an ugly hack too, but easy to pull of.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
5200 vs. 7800
in Atari 7800
Posted
Eh, DMA controllers generally need to halt the CPU, after all they're going to use the bus autonomically, which isn't going to work if the CPU at the same time messes around with it.
The reason why one makes DMA devices is that they're still faster because they "know" what to do without fetching instructions from program memory. On the GBA, large memory copies are often better done using the DMA controller. During the copy operation, the CPU is halted, but overall copying memory using the DMA controller is still faster, because for copying with the CPU you'd have to write a loop, and the CPU will spend large amounts of time fetching the same few instructions over and over again. The DMA controller on the other hand reads/writes just data.
Or am I getting something utterly wrong here ?