cd-w

In theory it could be done, but someone (not me) would have to write a text kernel for Batari basic containing the assembly code for 32-character text. Chris

The best that can be done on the 2600 currently is 32 characters (with some flicker), though not using batari basic: http://atariage.com/forums/topic/180632-32-character-text-display/?p=3441499 Chris

Have you optimised the sprites with D00d yet - I'm interested to see how much space that saves?

Dropping the attract mode to fit in more samples seems like a good compromise to me. Chris

The utility that you need is makewav: http://www.romhacking.net/utilities/712/

OK - I never expected this to generate such strong feelings! Never let it be said that I don't listen to feedback, so I have decided to keep Hunchy 2 in the store. The main reason that I wanted to remove it was my own dissatisfaction with the finished product - I'm now planning to tidy it up around the edges and release an updated version, though it may be another decade before this happens! Apologies to anyone who purchased a copy on the understanding it was being discontinued. Thanks for all the feedback! Chris

Hi Thomas, Can you say more about why you see this as a dangerous trend? IMO the AA store could use some pruning of the weaker titles - I'd personally like to see it as a showcase of the best homebrew that the 2600 has to offer (quality over quantity). For Hunchy 2, the ROM is freely available, so nothing will be lost as it can still be played on Stella, using a Harmony Cart, and even on the Flashback Portable. Is your main concern that collectors will push up the prices of the unavailable carts to insane levels? I agree from a technical perspective that it doesn't make sense to compare a 4K game against the latest 32K DPC+/CDF releases. However, I suspect the majority of folks purchasing homebrews are not aware of these details. All they will see is that Hunchy 2 doesn't compare favorably against titles like Stay Frosty 2? I'm concerned that someone will purchase this title based on the high reviews and come away with an unfavorable impression of the 2600 homebrew scene. I would also like to purge this title for personal reasons - this was my first 2600 title and I really should have spent more time polishing it around the edges. The sound effects are poor, there are not enough levels, and the presentation is amateurish. If I had more spare time, I would produce an enhanced version to correct these flaws, but this isn't likely to happen anytime soon. Chris

I have asked Al to remove Hunchy II from the AtariAge store at the end of the month. It has been available for 12 years, and in that time the quality of AA homebrews has increased to the point where I no longer think this game represents good value for money. If you still want to obtain a copy of the game on cart, this is your last chance: https://atariage.com/store/index.php?l=product_detail&p=330 Chris

The new sample sounds awesome - I hope you will have enough space for the rest? Chris

For my own homebrews: 1) Juno First 2) Star Castle Arcade 3) Chetiry Chris

I'm wondering if it would be better to have the sprite data in C, rather than ASM. The problem with the ASM version is that the C compiler can't do anything to optimize all the references to the sprite data, and so a lot of the binary is just offsets into memory. Instead of: AsteroidA: .byte %00110000 ; 0 .byte %00111010 ; 1 ... AsteroidAHeight = * - AsteroidA AsteroidID = * - ImageHeights .byte AsteroidAHeight .byte AsteroidBHeight .byte AsteroidCHeight You use: typedef struct Asteroid { char height; char[] data]; } ASTEROID; ASTEROID asteroids[3] = {{12, {18, ...}}, {{13, {18,...}}, {14, {20, ...}}}; This would require a lot of work and wouldn't necessarily result in a big saving. Actually, that wouldn't let you overlap the data. I guess you'd actually need something like: BYTE spriteData[] = { <all sprite data> }; typedef sprite { short start; char length; } SPRITE; SPRITE asteroids[3] = {{100, 12}, {112, 13}, {125, 14}}; And then we are back to offsets that can't be optimized ... Chris

The following magic will tell you which functions are using the most space: arm-eabi-readelf -sW testarm.elf | awk '$4 == "FUNC" { print }' | sort -k 3 -n -r Which shows the top 10 functions by size (3rd column is the size) are: 326: 00000d99 1200 FUNC GLOBAL DEFAULT 2 InitLevel 274: 00001299 936 FUNC GLOBAL DEFAULT 2 MenuVerticalBlank 294: 00001c41 808 FUNC GLOBAL DEFAULT 2 DrawSprite 233: 00001f69 688 FUNC GLOBAL DEFAULT 2 ProcessJoystick 415: 000019ad 660 FUNC GLOBAL DEFAULT 2 PrepScoreRadar 206: 000034bd 636 FUNC GLOBAL DEFAULT 2 MoveFormation 375: 00003bd5 632 FUNC GLOBAL DEFAULT 2 MissileCollisions 324: 00002219 588 FUNC GLOBAL DEFAULT 2 DrawMissile 316: 00003e91 564 FUNC GLOBAL DEFAULT 2 MoveEnemyShips 392: 00003739 536 FUNC GLOBAL DEFAULT 2 StationMissiles InitLevel and MenuverticalBlank are taking almost 1KB each, so are probably good candidates for optimization. Chris

Cool - have you considered adding a random element to the levels, e.g. randomly adding an small offset to the coordinates, or flipping the station orientations, so they are not identical every time? Chris

I think you could save a lot of space by packing the level definitions into bytes. It looks like you use co-ordinates between 0 and 1023, but I suspect you don't need all that resolution? You could divide the coordinates by 4 to fit into a byte, and then multiply by 4 when you read the values? The HS and VS issue could be solved by having 2 lists, e.g: a level with 2 VS and 1 HS station: typedef BYTE unsigned char; const BYTE alpha_1[] = { 253/4, 504/4, // ship starting X, Y location 2, 1, // station counts 320/4, 255/4, // station 1 X, Y location 224/4, 320/4, // station 2 X, Y location 96/4, 576/4, // station 3 X, Y location }; Chris

Feel free to upload the source to the CDF thread and I'll see if there are any obvious ways to save space. I'm sure Thomas will also be able to find a lot of innovative ways to reduce the size. Chris

Great progress (again) - looks like spy ships and e-type missiles are really the only things missing? Chris

This is coming along very quickly! Not sure how you find the time Afraid I haven't had a chance to look at the 7800 CDF issue again - maybe next weekend. Chris

One more binary - this was my attempt to reboot the project using the SARA superchip, instead of the Supercharger. Just a 1 screen demo, but a nice kernel nonetheless. Chris popSARA.bin

I'm afraid this is my fault - my personal circumstances have changed such that I can't take on a project of this size for the foreseeable future. Ivan spent a lot of time completing the sprites and animations, and it would be great is someone else could take on this project. Chris

Haven't tried it, but these mame invincibility cheats for bosconian could be useful for determining firing behaviours? http://www.mamecheat.co.uk/forums/viewtopic.php?t=324 Chris

Might be some useful info here - http://www.vizzed.com/boards/thread.php?id=80884

You are welcome to put Juno First up there (https://atariage.com/forums/topic/125269-juno-first-final-version-atari-2600/). Chris

This is coming along great now - looking forward to hearing the speech.. Chris

Cool - I'm guessing the compiler was inlining the setPointer and setIncrement functions already. Chris

You probably know this already, but the following command is very useful for figuring out where the space is going in your code: arm-eabi-objdump -D main/bin/testarm.elf Even if you don't understand the ARM/Thumb parts, the dissassembly give you a good idea of the length of each function. I can see that MenuVerticalBlank and SetGameDatastreams are taking up a lot of space. It seems that the compiler is not smart enough to optimize all those setPointer and setIncrement calls. You could probably save a lot of space by using loops, e.g: for (x=0; x<12; ++x) { setPointer(DS_LOGO_A+x, MAIN_MENU_GRAPHICS_RAM + x*LOGO_HEIGHT + ((x % 2 ==0) ? offsetA : offsetB)); } The setPointer seems to be particularly bad, as a separate 4-byte pointer is being stored every time. I suspect that using an offset from a fixed address may work better ... Chris