This is kinda cool. Somebody labelled the memory map of various SNES games. In some cases it's just where the music is. In others, it's audio, game assets, enemy definitions (strength), etc. Pretty cool.

Updated compile commands to generate debug info. -g generates extra symbols (all symbols). -Ln generates a labels file for Vice. -moncommands feeds the label file to Vice. Then you have to start "the monitor" to do debugging by clicking "Activate Monitor" on the File menu. Then you can do "m .MySymbol" to dump memory, and some other things.

Still haven't figured out if there's a nice way to place breakpoints inside code. There is a command accepted by the label files to represent a breakpoint, I just don't know how to automatically emit them.

Anyways, I think I'm happy with this test. I can see the effect of Bad Lines, and I can see my refreshes getting out-of-sync. I would like to fix the bottom glitch and improve the sync, but I'm certainly understanding the C64 better.

Now I'd like to know how difficult it is to play back SID audio. I'm guessing its a matter of exporting SID data and calling the output as a function every frame but *shrug*.

EDIT: Yep. Sounds like PSID's are exactly that. File Header with an offset to the Init and Play Functions.

I think emulating SID output is not easy/trivial or straightforward. I read somewhere, the output on the original hardware goes through analog filters. Also, there is probably many different sound/tracker/whatever formats for storing/compiling audio on the C64, making it impossible for there being a single way of playing "SID audio".

On the C64 itself, I think audio playback can be handled as a parallel process automatically after punching the parameters into the respective memory addresses, so it might not even be necessary to call anything each frame after the playback has been initialized, unless the audio data must be streamed from disk or otherwise generated at run-time in a way not already handled by the sound chip itself (would have to look into C64 trackers to research that).

I am torn between so many things and find it difficult to make a decision on where I want to direct my attention (options include but are not limited to: Drawing, Pixelling, Refugee Lib, learning C64 Assembly, giving Allegro 5 another go (possibly resurrecting the Spacegame project and/or porting all my stuff to A5), optimizing my Arch Linux system and setting up a fresh/clean development environment in there (learning/evaluating several IDEs like Geany, LiteIDE, Bluefish, Emacs), getting into music composition (using Rosegarden and/or LMMS)) ... seriously... there is too much interesting stuff to explore in a single lifetime._________________0xDB

Forgot to mention last night, I did some digging on the SNES's 65816 CPU (i.e. 16bit 6502).

I'm starting to understand why the SNES has such a lack of homebrew: There isn't a good 16bit 6502 family C compiler out there. Everything else is well covered (6502 via CC65, Z80 via SDCC/GBTK, 68000 via GCC).

That said, the 65816 is backwards compatible with the 6502, and actually starts-up in 6502 mode, which means less address space (64k max, i.e. 16bit). I think some of important stuff on the SNES requires access to the full 24bit address space though.

So it sounds like SNES dev is either a fight with a sub-par C compiler, or Assembly.

EDIT2: The LCC port is from 1994 (LCC 1.9). LCC has received minor updates since Y2k, but the documentation suggests the code may be too old to upgrade. https://github.com/drh/lcc

EDIT3: Yep. Just did some digging through the LCC's. The old one, dude wrote a custom way to generate operations, a pair of "optX.dag" files that list operations and assembly instructions for implementing them. New one, there are these massive "blah.md" files that list operations, and you re-implement them for your respected architecture. Sadly, LCC has no optimization support what-so-ever.

EDIT4: And just for reference, TCC also doesn't do optimizations. "-Ox is ignored"

Alright. So it seems the only decent C compiler for SNES is the WDC C Complier (WDCTools), which costs $40, but is currently not available for purchase.

EDIT5: Seems it might not be that great after all.

Quote:

This version of the compiler comes with a post-pass-peephole optimizer called WDC816OP. This optimizer operates on the assembly language output of the compiler and performs a number of optimizations that generally save about 10 percent on code size depending on the program. To invoke the optimizer, use the -SP option. If -SP is used in conjunction with -A, the output file will contain the optimized assembly language. Note that the optimizer makes assumptions about the format of the assembly language output of the compiler and will not operate properly on hand-written assembly language programs.

Or all things considered, maybe that's actually good. *shrug*

I guess whatever has the best workflow is the best option. WDC is Windows-Only and $40. LCC is ancient (and I'm not even sure what assembler/linker it uses). TCC, at least, is part of a complete package with WLA_DX.

Given how weak these 6502 devices are though (C64, NES), you'll probably want a hybrid approach. Some ASM here and there, since the optimizer doesn't necessarily generate best-case code (even though the 6502 really can't do much).

2 of the 4 GameBoy games I worked on we also did hybrid C+ASM, but back then (2001) the compiler has some of the most insane bugs. It looks like SDCC has continued to be worked on since, so I'd expect things to be better today._________________Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar

Last day of 2014 is tomorrow (today if you're reading this). I think I may start a new tradition:

On December 31st, do one quick project before 2014 ends. I.e. a "Last Day" project.

Of course, I'm posting in the Commodore 64/6502 thread, so I'm obviously thinking C64. I want to do NES eventually, but I've done more C64 homework. Next year's Last Day project can be NES or something.

To make things more interesting, I'm going to take a look through my old game design notes from when I was a kid, and see if I can find something to inspire me. Something that was beyond my skills then._________________Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar

PoVModeratorJoined: 21 Aug 2005
Posts: 10971
Location: Canadia

Posted: Wed Dec 31, 2014 9:58 pm Post subject:

One of the better references for the VIC-II Graphics Chip, 5 part series.

And it seems at the end of the 1980's, some dude put together replacement ROMs for the c64 and 1541 floppy. If you swap out the chips, instead of getting 400 bytes/sec read speeds, you get about 2.4k bytes/sec (6x faster). Fully backwards and forwards compatible with all software, even fast loaders.

Some things you'll need:
A resistor 470.
A capacitor 47 uf.
A capacitor 0.1 uf.
An LED (not mandatory).
An SD Card port.

I'll assume you know how to do advanced things like soldering and modding, so I'll leave you to your own devices. You should be able to get one built with all the info on that page, if not, you might want to swing by the SWAT forums and speak with the creator of Dreamshell, mister SWAT himself for a few pointers.

You can connect the SD card as an example on the application of the SPI interface. It can be used without any particular problem is a simplified version is omitted, such as the detection of the write-protect switch on the control and power, however.

Can be written in block 4 seconds (500Kbytes/sec) and output files to SD card BIOS ROM 2MBytes of DC to try. The speed will be equal to or greater than that of the BBA lip when converted to the draft GD-ROM, speed may be slightly lower, to strengthen the recovery error CRC error checking, etc. in order to increase the reliability of the written file.
(This is identical to the circuit in kind of photograph is using VHC244 on hand.)

PS: It was using the HC126 to buffer in the previous circuit, I changed to the circuit without delay buffer for the buffer will affect the speed. pic

I leave here the demo software SD card. screen shot sdcard_test.bin
SD card and message SD Card set and hit CR key!! Use will appear in the ip-upload, binary run when you start
I will start by pressing the carriage return key to set. Bios.bin flash.bin and especially if there is no error message
Files will be written. On the time stamp of the file is using clock Dreamcast.

EDIT2: some French instructions for literally hacking up an SD card reader and soldering it directly to a Dreamcast serial port.

I've playing around with cc65 for a few days. Very cool and simple; the allure of doing c64 stuff with C+ASM is just too much to resist. I must... I must!_________________NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)

PoVModeratorJoined: 21 Aug 2005
Posts: 10971
Location: Canadia

Posted: Mon Mar 09, 2015 6:10 pm Post subject:

Do eet!_________________Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar

PoVModeratorJoined: 21 Aug 2005
Posts: 10971
Location: Canadia

Posted: Fri Mar 13, 2015 5:45 pm Post subject:

As promised, here's where I left off doing the 'Gardez 64' demo.

Again, I cheated, without file loading. I bin-include the SID file, in an assembly file, then copy where it should be in the C file. I'm pretty sure $7e was how many bytes to skip in the header.

Once I have the data where it's expected (0x4000), I can call the short assembly functions SIDInit() and SIDStep() from the C code.

I also wish I had a huge, wall-sized map of the C64 memory map I could hang somewhere, just because...

Again, allow me to say (if I hadn't earlier) that I'm hugely impressed with the amount of progress you made in just a few days. I've been banging away at it a few hours a night this week, and I feel comfy with it, but I've got some important gaps in my knowledge still.

Also, this page is super useful for when you need a quick and dirty sine LUT banged out._________________NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)

PoVModeratorJoined: 21 Aug 2005
Posts: 10971
Location: Canadia

Posted: Fri Mar 13, 2015 6:07 pm Post subject:

The code I use for SID playback is in the assembly (.s) file. You can't see it because the forum lacks syntax highlighting, but that inline code is commented out. I forget what the inline assembly was about. I think it may have been an early attempt to re-jig a linker script solution, so the addresses suggested don't exactly make the most sense. Either way, if you wanted to know how to do inline assembly, that should be a decent starting place.

To be fair, I've shipped games with tools exactly like cc65 before, so I knew what I had to do. Just had to remember how to, and learn about the VIC and 6502.

EDIT: Oh right, here's "Vickers.h". A library I was starting to write.

c64.h (included with cc65) defines some symbols like VIC, CIA2, etc, each a piece of hardware in the C64. It gives you nice names for the hardware registers in the memory map.

_________________Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar

SiroccoModeratorJoined: 19 Aug 2005
Posts: 9470
Location: Not Finland

Posted: Fri Mar 13, 2015 6:30 pm Post subject:

Quote:

The code I use for SID playback is in the assembly (.s) file. You can't see it because the forum lacks syntax highlighting, but that inline code is commented out.

I noticed that after I posted ^__^ Gotta slow down and READ.

I started working on a dirt-simple lib for what I feel will be commonly used things, but I'm not going to put too much effort into it until I bang out something to confirm I really want to this on a c64 (I'm like 99% certain, but the world is an uncertain place, so there you go).

I'm also running into little oddities like fseek not existing (CMB doesn't support moving the file pointer!) and there not being sin/cos functions, which I sorely miss. I will eventually want to do simple 3D projection of points, so I'll need proper sin/cos stuff, but for a now a LUT makes my sprites bounce like I want them to._________________NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)