TomSon

Yes, it's a 32 char kernel - not a modified system. All the data is put into register immediate loads (with cycles to spare) so the drawing starts like this: even_loop: ; AB CD EF GH IJ KL MN OP QR ST UV WX YZ 01 23 45 TXT_2LINES_EVEN $77,$36,$77,$35,$71,$54,$56,$26,$26,$37,$55,$AA,$57,$E4,$77,$AE,DARK_BLUE,DARK_BLUE TXT_2LINES_EVEN $55,$45,$44,$45,$21,$54,$75,$55,$55,$42,$55,$AA,$51,$A4,$11,$A8,DARK_BLUE,DARK_BLUE TXT_2LINES_EVEN $76,$45,$66,$57,$21,$64,$55,$56,$56,$72,$55,$A4,$72,$A4,$77,$EE,DARK_BLUE,DARK_BLUE ... and the macros seeded with the data to be displayed - with just a little cycle-handholding later on for bank switching and scanline end checks (50/60hz). Obviously it's interleaved: in the default menu output I am using a 3x5 font doubled to 3x10 so the odd and even scanline data is the same to minimize flickering. I've also got a 3x7 font menu in there but that flickers too much on my TV for my liking - the default menu in PAL60 looks excellent to my eyes, at 50Hz bearable (but still ok).

yes, that is the 'FA' hardware base, just started it and tried to play (no idea what I need to do running around in that 3D maze) but looks as expected (w/ funky colors; ntsc on my pal vcs..) Reminded me of adding a picture of the info page that I forgot to mention - 'game select' in the menu brings up this page showing what the Tiara will use for the selected binary as cartridge hardware, either determined automatically or via file ending. I've also added and display the same checksum code as Stella uses both for a quick sanity check and to look up and display more metadata - just filling the flash of the chip, really.

more specific then: when reset the 650x starts with specific cycles, amongst others documented here: http://www.pagetable.com/?p=410 so there are always accesses to (1)ff, (1)fe before accessing fffc when the 650x comes up triggering the FE bank switch hw.

hehe, I'd actually have to quote us both (from: http://atariage.com/forums/topic/261488-reset-sp/) it's a feature of the 650x reset behavior and can be beautifully watched being init'ed on http://visual6502.org/JSSim/

yes, Stella always starts at bank 0, too, it'll crash here if I manually switch to bank 3 right after a manual reset. Actually: I wondered before why 'randomized registers' existed but not a randomized bank option - except that randomizing banks would need a list of cart. hw where this could/should be tested - not only the harmony ones but also 'FE' for example comes up in a defined bank, anyways, so randomizing this would be wrong again..

I know . nice display, btw Are there other examples of storing data ? I might add this still since it's reasonably easy to do (in principle) and I myself like to play for highscores. Ideally I like to have a unique identifier for a file so that I know which dataset belongs to which cartridge but this doesn't seem to exist here and I would have to use, say, a checksum of the binary as a substitute. Not ideal, especially when developing since it changes all the time. Any ideas ?

Hmm, the one I just looked at again is 16K - the reset vectors are ffe8 in all banks and the opcode there is a nop FFF9 in banks 0-2 but in bank 3 it's a nop FFF6,X. So if you start in bank 3 and the instruction is loaded from this bank it'll likely not end up accessing ffe9 (depending on reset X value) but more likely stay in ffea due to the last adr. fetch. Bank 3 is actually almost empty otherwise -FFs-, just 0x87 bytes or so at the start of the bank are used (looks like init. code, too). So I probably have got a weird binary here.. Oh: and I want to apologize for singling out (by mentioning it) 'Stay Frosty' - I just remembered this for some reason first. I should have dug up the above reset code w/o actually naming it but I was almost out of the door for a day trip (beautiful weather here in the moment)

Concerning menus - I use a 4k menu bank (times eight - literally just draws a bitmap and changes the bg color once per scanline, using a few flags for necessary, other stuff (e.g. length of frame for 60Hz/50Hz etc.). Every frame the menu hands over the input bits and the firmware draws/sets up whatever is needed. So everything is drawn by the firmware using automatically generated offset lists per menu to directly poke in new values. The hardware is an ARM stm32f4 processor, I've used two different versions and the one here uses the f405 plus an additional 16MB flash for the usb disk. Switching to a bigger one (for more RAM) would be easy but I've got no bin remotely using the 160k I currently have for the VCS already so don't see a need yet. There is otherwise no fixed circuit hw between the cart. slot and the ARM - everything is done in sw. on a per cycle basis and the ARM is manually init. fast enough to supply the 6507 with the reset vector. behavior: Almost all cartridges out there do a 'do not care for value' read of those registers. Some a write, just as a trigger. Some mix both. A few ones do need to read an actual byte value, I think one even expects to read a byte from a specific bank (it's a coin toss if the expected data would be from the current bank or the one switched to or valid at all on actual, 'simple' hw). Frequently this is done by putting code directly in the bank registers and pointing the reset vector to it or jumping to it (e.g. Man Goes Down or Ms.Hack). Writing is a problem for the Tiara since a 6507 write together with the uProc putting data on the bus does lead to problems - bus stuffing does not work with this uProc (or at least I couldn't get the expected result). It reliably crashes the bus emulation. I'm seeing similar behavior with the 6809 where I tried this, too, trying to overwrite one specific bit in the Vectrex ROM code for a test. And I can't imagine 'real' hw to be magnanimous about this, either, depending on actual setup. So a game mixing reads with expected return values and writes to bank regs. won't work w/o needing some hand-holding (again: Ms.Hack). At the start I randomized the start bank of hw where I believe it isn't fixed at startup but quite a few home-brews had problems - but not the old games - that I stopped this right away. This is weird because most of those home-brews actually do have code behavior to init. themselves to a bank. (just to name one: 'Stay Frosty' dies starting in bank 3, works in other banks (is X==bank guaranteed on harmony, maybe ?!). The harmony, when starting an ARM routine, seems to still return the last byte over and over (or zero, can't remember, but it was fixed based on expected return values) while being busy. The Tiara doesn't - bus values are floating/semi-random. So something like Star Castles (bit 1ff4, bvc xxx) check when storing hiscores doesn't work (which is why I haven't added storage functions so far) - it would need a presence check before.

So.. I’ve spent quite a bit of time with my Atari during the last winter and finished my project a while back but never actually posted anything about it so I wanted to put something down here at least. So, what is this project (btw, name is 'Tiara' for now) - I would explain it as a VecFever for the 2600 but since you do not know what my VecFever is: it’s a versatile hardware that for one thing loads binaries off of a disk, analyzes them and creates the hw environment the loaded bin needs to run in a 2600; it stores the state immediately before starting any game selected in the file browser and upon power-cycling comes up just as it was pre-start. More crucially, since I build this as a development system, it let’s you upload a new cartridge to try out immediately via USB, if it’s in development mode. This is simply enabled by flipping a switch on the console at any time in the menu - e.g. one of the ‚difficulty‘ switches, if enabled by a menu option. Exactly the same setup that I like to use for developing my Vectrex games: a ramdisk appears via usb on my dev. machine where I can upload anything; so fast turnaround times. Probably the first thing someone will ask is which 2600 hw is supported so here’s the current list: . 2K/F4/F6/F6SC/F8/F8SC (Atari 2K-32K ROMs with or w/o Superchip) . 3E (128K ROM/32K RAM in the moment) . 3F . AR (Supercharger) . DPC (Pitfall 2!) . E0 (Parker Brothers) . E7 (16K M-Network) . EFSC . F0 . FA (e.g. Omega Race) . FA2 (e.g. Star Castle) . FE (e.g. Activision Decathlon) . UA special case is DPC+: the 2600-side has been implemented (e.g. more and fractional fetchers, 'fast fetch') but cartridges using the Harmony processor directly will not work. but since the firmware can be upgraded at any time simply by starting an update file using the file browser this can be expanded easily. In the moment I don’t have any bins here that do not work, except for certain Harmony-ARM-binaries. However, while developing this I came across a few home-brews I’ve analyzed that do assume a specific hw. behavior the Harmony cart. seems to have - but not the Tiara - that can be problematic, mostly surrounding the bank registers. Since only the Harmony cart. existed so far and all those things are easily fixed on the fly I’ve added patches for everything I’ve encountered. These were just a handful of games anyways (5 or six if I remember correctly). The menus also can be selected and changed on the fly since the 2600 is just used as a bitmap-terminal by the firmware. Same with color palettes, frequency or other options. Are there any bugs I know of ? Maybe one: I am not happy with the sound output from DPC cartridges at the moment but not having any reference to check against (the Pitfall 2 cartridges I've bought all arrived dead) I’ve got nothing to compare it with. Sound is ok(-ish) but not as good as I hoped for. Because of this I haven’t added sound support to dpc+, either, yet. So, where to go from here ? The obvious next step now would be 7800 support: first a 7800 menu for a VCS Tiara that will use a higher resolution menu and then start a selected 2600 cart (if that’s possible). Then a dedicated 7800 Tiara that would allow to run 7800 cartridges, too, while also be able to run the 2600 ones. However I only investigated this for a weekend when getting a 7800 and realized that programming a 7800 menu would take quite some time for me - mostly learning the hw. and setting up another dev. system. And the 7800 I got is really terrible - it was enough to check that I could detect a 7800 by the initial checksum test and verify that the Tiara works there, too, but I was tempted to throw it away almost all the time while doing so (sound has problems, colors are seriously off and the controller only works sometimes). So my first and only impression of the 7800 was terrible and mostly due to this I haven’t spent any time on this anymore. Still, I intend to maintain this project for quite some time - it shares code with the VecFever which makes it easy - and I still wonder about 7800 support so if someone out there thinks this is worthwhile (and convinces me) I might develop this further, either on my own or with someone helping with the 7800 menu-side. The hardware itself is (almost) finished - the current pcb dimension already fits perfectly into Atari cases but a capacitor needs to be moved a bit for the earliest cases or it might get dislodged there by the sliding plastic cover that ‚protects‘ the pcb when not in the console. The 'younger' cases (e.g. w/o sliding plastic or the ones with two larger springs) work fine. Next iteration will fix this, of course. What else..: at this point I have no intention to make the Tiara available to anyone (except .maybe. to other developers, who want to take a look at this). I’ve developed this mainly to learn about the 2600 and ‚since I could‘. And I really do have fond memories of my Atari VCS, so I enjoy having my own hardware feeding it with data, Thomas p.s. and I finally ‚beat‘ H.E.R.O., 3 decades late but still that was one of my goals

Hmm, I'm not certain that this is an IC issue - I've seen similar behavior in the past: the 7ADB bios version has a slightly different joystick measurement routine to the older ones so it doesn't surprise me that some effect might happen on a 7adb but not an older one. This is usually a non-issue depending on what happens afterwards. I actually saw a behavior a .lot. worse which I had to specifically fix in an old VecFever menu a long time ago: the 7ADB joystick analog measurements are actually fixed, there's a bug in the older bios versions, but they don't zeroref just like the old ones, either, which I'd call a new bug - this is probably the culprit here, not the actual fix.

Exactly, this is very easy - if you can get hold of a transparent case and know where the hot part of a soldering iron is: the LED fits exactly in an area between the voltage regulator and the processor without having to shorten the legs. For a first test you don't need to solder (first pic), just put it in and power it via usb.

Thanks from me, too, just got my very first Atari xe (xegs) and the start button didn't work - I would have opened it up and started eyeballing/measuring if I wouldn't have seen this thread right away - after pressing it a few dozen times or so it came back to life and the self test shows now problems, so I can play a few games now..

No, I've got no intention to release the games separately any more - R.Arena and Head On also run (a bit) better on the VecFever (taking advantage of the calibration setting) so I consider them the 'definitive' edition, anyways. Plus there's a nice, secret level in the VecFever Robot Arena version that I couldn't squeeze into the 64k rom version however much I tried in the end..

Hi, I just wanted to quickly introduce my finished Vectrex project, called ‚VecFever’. So, what is it meant to do ? Well, basically anything I could think of so far - it’s my development system, it’s a usb stick, it’s a usb ramdisk, a multicart, a video player, a music player, a ‚magically change old games into games with hiscore tables, that are also saved’ cart. etc. So it can run any Vectrex binary - and you can .always. go straight back to the menu via the reset button w/o any patches needed - plus allow games to store data on it, or use more than two 32k banks, or load variable-sized, tiny data packets ideal for videos. One thing I should probably mention specifically is how the multicart. part works: the VecFever includes a file browser that let’s you navigate and start anything on the filesystem of the disk; entries are automatically sorted. And as I said: this is my development system; I’ve finished three big, time-consuming games so far: Robot Arena, Head On and ‚the Core‘, all of which haven’t been released since they merged with the VecFever, too. The pcbs underwent a few iterations, mainly for production purposes and to get the dimensions perfect so that it fits into both old and reproduction cases and I’ve received the first larger run of final pcbs a few weeks ago and tested them successfully. So, what now ? I am still having trouble getting usb-shaped holes in cases made (and don’t want to cut them myself). This will .hopefully. be settled one way or the other in the next two weeks but if it keeps dragging on I might reevaluate whether to get cases anytime soon. Plus summer (vacation..) is coming which might delay things even more. So I do want to make them available but don't know yet when. And it all hinges on the cases since everything else is finished. Anyways, this is meant to be a short introduction so I should stop now, Thomas p.s. Here’s what they look like in four different cases, plus the games that now are part of it - and a special VecFever (with addition serial port) VecFever FAQ.rtf

Here's Carnival and Dark Mage as PAL60 - both were easy to convert (and I prefer playing in PAL60..). Carnival (PAL60).bin Dark Mage (1997) (Greg Troutman)(PAL60).bin

I thought I'll add one to the list that I like: here's 'Communist Mutants From Space' as a PAL60. I've lifted all palette info from the PAL version and injected it into the NTSC bin. I believe in principle the checksum for the supercharger pages would need to be adjusted but since all 'original' bins I've checked also have wrong checksums I decided against it for now. Communist Mutants from Space (PAL60).bin

hehe, every byte counts, I know But that's actually a good hint - I myself don't have a rom < 2k and have not checked whether they exist and how they are treated in Stella. I assume it's just mirrored in the entire 4K and a 4K mapper used. Very interesting that it fails on the flashback portable. I'd be also interested to know whether the Harmony does the same thing (I really have to order one asap myself). I am investigating bank switching in general and initializations in particular in the moment which is why this came up - the FE one is automatically set to bank 1 by the reset mechanism of the 6502 (the reset vector fetch looks just like a jsr fffc when just snooping the cart. bus) which makes this 8k bank switch even more elegant in my eyes.

Quick test to see whether SP is correct after reset, displays either an orange screen if correct or black one if SP != FD. ORG $F000 START_FLAG .byte 0 ;############################################################## ; ; Reset handler - clears all mem. and regs and inits ; the static regs/mem ; ;############################################################## Reset: tsx cpx #$fd beq Reset2 CLEAN_START reset_entry STA COLUBK ;3 JMP frame_handler Reset2 CLEAN_START LDA #ORANGE ;2 jmp reset_entry frame_handler: LDA #$02 ; A = VSYNC enable STA WSYNC ; Finish current line STA VSYNC ; Start vertical sync STA WSYNC ; 1st line vertical sync STA WSYNC ; 2nd line vertical sync ldy #37 LDX #$B0 ;2 LSR ; A = VSYNC disable STA WSYNC ; 3rd line vertical sync STA VSYNC ; Stop vertical sync vblank sta WSYNC dey bne vblank sta WSYNC STA VBLANK ;3 SET_COLOR0 STX HMP0 ;3 STX HMP1 ;3 ldx #11 norom stx WSYNC dex bne norom sta WSYNC ldx #180 norom2 stx WSYNC dex bne norom2 LDA #$42 ;2 sta WSYNC STA VBLANK ;3 ldx #27 overscan: sta WSYNC dex bne overscan beq frame_handler frame_handler_end: ORG $FFFA .word Reset ; NMI .word Reset ; RESET .word Reset ; IRQ tst_sp.bin

I just verified that SP is indeed FD starting a test bin on a 2600 in a ROM so this is a bug. It may even be a bug of the harmony cart. depending on how they init the sp before starting the loaded cart.: I do not have one myself to test this - and I don't know how to attach my test_sp.bin here (yet..).

First off: hi to everyone on this forum - I am brand new to VCS programming and have extensive low-level hw programming background, (also programming retro hw) but so far not on the 2600. So, just now I stumbled upon a possible bug in Stella - the reset SP is according to this document: http://www.pagetable.com/?p=410 at 0xFD but in Stella it is 0xFF. Since every cart. on the planet seems to init. the stack right away anyways this is not a big deal but still.. p.s. void M6502::reset() SP = BSPF::containsIgnoreCase(cpurandom, "S") ? mySystem->randGenerator().next() : 0xff;

Sony PVM-9045QM ntsc warm 28/215/19 cold 29/213/20 pal warm 36/254/22 cold 39/249/24