Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

TomSon

New Members
 View Profile  See their activity

  • Content Count

    46

  • Joined

  • Last visited

Posts posted by TomSon

  1. Posted

    I count 32 characters across in his screenshots, which puts it at 128 pixels.

     

    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).

    • Like 2

  2. Posted

    Awesome work! :)

     

    Is CBS RAM (Tunnel Runner) supported?

     

    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.

    post-50731-0-83479300-1496499381.jpeg

    • Like 3

  5. Posted

    Mine does NOP $FFF6,X too (sorry, looked at an old document which describes $1C wrong).

     

    Nevertheless, within Stella the game always starts correctly, even with randomized registers. But it seems that Stella always chooses bank 0.

    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..

  6. Posted

    The Yin-Yang display while loading does exactly the same.

    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 ?

  7. Posted · Edited by TomSon

    The last bank of the Stay Frosty ROM I have looks fine (startup vector and bank switching to bank 0).

     

    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)

  8. Posted · Edited by TomSon

    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.

    • Like 2

  9. Posted

    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 :)

    post-50731-0-35284700-1496337304_thumb.jpg

    post-50731-0-76953600-1496337343_thumb.jpg

    post-50731-0-55254500-1496337477.jpeg

    post-50731-0-62724000-1496337682.jpeg

    • Like 9

  10. Posted

    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.

  11. Posted · Edited by TomSon

    you can add your own you just have to solder 4 points, the part costs less than a dollar. finding a clear shell will be a bit more difficult although there is suppose to be a batch coming soon.

     

    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.

    post-50731-0-31092300-1495817227_thumb.png

    post-50731-0-62355900-1495817265_thumb.png

    post-50731-0-45921800-1495817384.png

    • Like 4

  12. Posted

    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..

  13. Posted

    Hi Thomas, please put me on the list - seems to be a must-have for me. Are the games included intended for a physical release (The Core, Robot Arena and Head-On)?

     

    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..

    • Like 1

  14. Posted

    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)

     

    post-50731-0-77851800-1495371475.jpeg

    VecFever FAQ.rtf

    • Like 23

  16. Posted

    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

    • Like 3

  17. Posted

    Why a 4k rom? ;) BTW test fails on the Flashback portable.

     

    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.

  18. Posted · Edited by TomSon

    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

    • Like 2

  19. Posted

    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..).

  20. Posted · Edited by TomSon

    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;

     

    • Like 3
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...