Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


RevEng last won the day on February 6 2014

RevEng had the most liked content!

Community Reputation

3,738 Excellent


About RevEng

Profile Information

  • Gender
  • Location
    bottom of the stack

Recent Profile Visitors

41,995 profile views
  1. Thanks for the typo catch, and the nitpick - I'll stick with BEAD. I'm not sold on the requirement that the reset vector should be ignored when present... it would certainly make it harder to convert commercial games to bead. It also adds friction to adoption by homebrewers. The reset vector adds a small bit of handling code, but I think it's worth it.
  2. Ok, I took a first whack at the spec. Let me know if you have any input. Also let me know how (under what name) I can credit you in the doc!
  3. I was thinking more like this... - DSS == Data Type and Size \- %000 : 16K @ $C000 - $FFFF - %001 : 32K @ $8000 - $FFFF - %010 : 48K @ $4000 - $FFFF - %011 : reserved - %100 : reserved - %101 : 4K @ $1800 - $27FF - %110 : 16K @ $4000 - $7FFF - %111 : reserved ...so at some point the middle reserved values can either become 2 formats, 1 format+1 segment, or 2 segments. (Without mixing up our grouping of formats and segments.) The b78 extension sounds good. The test beads shouldn't be a problem, for full format types anyway. The first place I'm putting them is in 7800basic, so I can just recompile any of the code samples or games. I'm also planning to work on a reference loader, targeting XM hardware.
  4. Agreed all around! Any objection to swapping the reserved bit at %101, and the %100 segment? That way the 2 available reserved bits can be later used for either a full format or a segment, without splitting the nice grouping of formats and segments. When I get a chance I'll write up the spec at 7800.8bitdev.org, and update the first post here too.
  5. Super glad you're still plugging away at this. The 7800 needs it. This is the kind of game that makes other console owners envious.
  6. Indirectly the start location is there, but it's just not covering your scenarios. e.g. 16k would start at C000, 32K would start at 8000, etc. So maybe some ram segments could be added to the formats? ; %00000nnn : 0=16k 1=32k 2=48k 3=128k 4=144k [email protected] [email protected] [email protected] The loads into ram segments would't have the 6502 vectors, so in that case the bead loader would just jump to the start of the segment. I'm also thinking that a segment load would as long as the natural segment length, if loaded from savekey. (since there's no EOF) Moving the reserved bit to MSB works for me. I also like the extended bead with descriptor string. [edit - Just considering if there should be a way to mark a bead as non-executable (ie. for data) and then string beads together. It would be neat, but too much scope creep.]
  7. Yeah, maybe the game can count the number of bounces the ball makes without touching the paddle, and past some threshold, start gently messing with the angle.
  8. I should have spelled it out, but the intention was for pokey to be strictly [email protected], which has become a homebrew standard of sorts. For this header to have meaning, we need a platform with RAM or equivalent, like XM, MPC, CPUWIZ's other cart formats - and $450 is common to all of those. It's trivial to modify commercial games to use [email protected] instead of 4000, so even those could be bead'ized. (though fitting the bead in would be a bit more work) I like the double-bead idea, with the base bead giving basic platform info, and extended beads giving future (hopefully esoteric) hardware options. That way first gen bead hardware might still be able to load software that specifies an extended bead, by simply ignoring it. On your suggestions for payload... with this header I'm not trying to do away with a78 headers for emulators. Rather I want to make it easier to load 7800 homebrew executables on real hardware, from sources that aren't trivial to seek through. I don't think the extended payload would be worth the extra parsing, when the reality is that we're not likely to see homebrew in Activision or Absolute formats. We're not having to prep AtariVox, controllers, etc., so they're not needed in BEAD. XM is covered by it's constituent peripherals in the current base bead. I think keeping the base bead features limited to a single byte, supporting foreseeable hardware, is key. I'm ok that this trades away some theoretical flexibility. I think it's more important for bead support to be cheap, both codewise and romwise.
  9. As a side project, I've been working on a rudimentary terminal program for the 7800. Some day I see the 7800 as being capable of downloading game binaries directly from online sources, or alternate media like a savekey. Games could even download their own updates, and run them from RAM. To avoid having to parse something like the A78 header with the 6502, I've come up with a succinct embedable header. The header doesn't need to actually be in the code path, but will only spoil the X register if it is. ; BEAD Header is just 3 bytes at the very beginning of the ROM... ; ; M1 M2 F1 ; $BE $AD $## (aka LDX $##AD,y) ; M1+M2 = magic ; F1 = format: ; ; %000000nn : 0=16k 1=32k 2=48k ; %0000nn00 : reserved ; %000n0000 : rof on (both bits) ; %00n00000 : pokey on ; %0n000000 : ym on ; %n0000000 : hsc on A device with a bios and semi-persistent ram might even scan certain memory locations for a BEAD header, or check the start of an inserted SaveKey, and offer to run the binary. Hoping that sharing this info might stoke some imagination.
  10. If you can free up any used memory from $22e4 to $27ff, then you can use "set extradlmemory on", and change to "set romsize 128k". That will give you 20 objects per zone, which should be enough.
  11. The 128kRAM format has 16k ram (from 4000-7FFF). If you're only using the extra RAM for the DL now, it looks like you're actually using 4K of that.
  12. I haven't had my Harmony functional for a while, so I haven't been able to try and recreate the issue. There were testers other than myself when I developed Spell&Speak, and nobody reported this problem. I can't say if it's emulation or what at this point.
  13. Not exactly your question, but I figured I'd point out that for BCD operations you use the hex representations of the decimal numbers. So "ADC #$10" instead of "ADC 10". The latter will mess up your BCD math for any operand greater than 9. (since $0=0, $1=1, ..., $9=9) Subtraction with BCD math isn't any more complicated than addition (use SEC instead of CLC), so I'm wondering if your problem isn't with the issue I've mentioned above.
  14. For sure the pokey will work. The hotspot would need to be fixed for MCP compatibility.
  15. The pokey situation is expected. Arkanoid uses a pokey at $450 (a typical homebrew location) instead of one at $4000 (the commercial location) because the game is already using RAM at $4000. Both Mateos and CC2 only support pokey at $4000. I think Concerto is the same, but not 100% sure on that. Arkanoid is using the 7800basic pokey init, which should enable and work with a XM pokey. Obviously this hasn't been tested with real hardware. So an "XM" version of the cart is possible in theory.
  • Create New...