Jump to content

Blackbird

Members
  • Posts

    138
  • Joined

  • Last visited

Blackbird's Achievements

Chopper Commander

Chopper Commander (4/9)

9

Reputation

  1. I purchased an Atari 5200, but I don't practically have enough space to display any 15x15" electronics in my house. I used to spend a long time reading how to make vintage video game consoles portable, so I figured it might be a good candidate to mod and stuff into a smaller package. This is loosely inspired by Kevtris' 5200jr project. For my 5200 "Junior" console mod, these are the requirements I decided on: No custom motherboard PCB (but yes to circuits that could be feasibly hand-wired, like on a protoboard) No custom-made plastic case Be repeatable with instructions Look authentic to early 80's consoles At the same time, support conveniences like AV ports, HDMI, or USB power supplies Status Right now this mod is still a work in progress, but here are my explorations and some in progress photos. Case: To make a console that looked somewhat authentic, my best reference here was, of course, the 5100 prototype that exists. This one resembles a miniature 5200 in aesthetic! Unfortunately I couldn't find anything which matched this 5200-like look, but, I did do a survey of various Atari clones of the period to see what came close. In doing so, the Sears Super Arcade II stuck out for a few reasons: It has four ports in the front, like a four port 5200 Its not a popular variant of the console, so I avoid the look of a 5200 stuffed into an obviously 2600 case... But its common enough I can acquire a case easily... And this variant came at the end of the 2600 lifecycle, and truly does look like a stepping stone to the 7800 design. A 5200 Jr. on the market could conceivably have had an updated, sleeker design as the 7800 were introduced. So here is my 5200 circuit board fitted into the Sears Video Arcade II case, temporary packing tape and all: PCB modification: Similar to miniaturizing a 2600 board, the first step was to cut off anything beyond the boundary of the RF square containing the CPU, GTIA, etc. (This handicaps the controller circuits, which I will need to address later.) Unfortunately the 5200 is still a massive PCB, so deeper cuts are necessary. Via the schematic, I worked out that the right side of the board holds mostly AV circuitry, which can easily be replaced and in fact would be unneeded with an AV mod. This leaves some stray controller circuitry, and the oscillator. Because the clock is essential, I dremeled an irregular shape of it off the board so it could wire it floating off the board. I put together a very basic AV circuit that only produces luma. (Actually, I did this first to make sure the 5200 works, since I don't have the right equipment to hook up an RF box to my TV). This will be replaced by a better circuit later. The clock is wired adjacent to it, though I will probably mount it below the board ultimately: It's a bit frankenstein at the moment, but it works! What's next: Since the console boots, I believe I've worked out that the basic mod is viable. Next is fix the controller circuits, modify the case with 5200 branding, and modify the buttons to be functional: Replace the AV mod with the UAV mod so I can visualize games in color (and ensure no RF components are causing interference) Wire the AV and USB cables through the appropriate slot inside the console Mount the oscillator underneath the board. (The bottom of the console has a drop space and much more room than on top) Create a protoboard for mounting the controller circuitry Recreate/fix the Port 1 and Port 2 circuitry Build the Port 3 and Port 4 circuitry (since I adapted the original console from a 2-port console) Wire the bottom four case buttons to be (On/Off, Start, Reset, Clear) Dremel off the old console nameplate from my 5200 shell Dremel off the standoffs from the top of the Sears shell (they don't allow the console to be shut properly, I'll need a replacement) Mount together and play! Figure out how to attach the nameplate to the new console, fix the lettering on the lower buttons, polish Thanks to: Tombstone for the Sears Video Arcade II shell. Bryan for making the UAV mod.
  2. Just the shell! I'll be supplying the guts. PM sent.
  3. I'm interested in purchasing a Sears Video Arcade II for a console mod I'm working on. I'm looking to avoid ruining a perfectly working console, since I won't need the 2600 internals. If you have one that is broken, needs repair, or is even missing a circuit board—that's perfect! An intact plastic case is all I need.
  4. Happy New Year everyone! Recently when redoing the VESWiki, I realized that the site could easily be expanded to include other consoles... Having attempted programming for the Atari 2600 before, I figured it may be worth trying to create a Wiki repository for all the programming knowledge for the 2600 that's been accumulated over the years. Take a look: http://classicdev.org/2600/ Much of the information is pulled from other, existing sites (the Mini-Dig and Bjars.com, particularly), now presented in a wiki format that anyone can register and edit. Some of the goals I'm working on accomplishing: Unifying and expanding old documentation. I've started doing this by converting over old text files (such as HMOVE Timing, TIA Color Chart) and expanding some other information (Reading paddles). Many code snippets are incredibly useful but have little context until you research them (SkipDraw, etc.) Also this makes it easily to add new documentation (reading Kid's Controllers, explaining SwitchDraw) to the site. New tutorials/information. The site currently links to several excellent tutorials (2600 Programming 101, Programming for Newbies) but it's always possible this could be expanded with other primers on TV syncing, sprite generation, TIA basics... Maintaining a list of disassemblies/tools. I went through the effort of converting over the disassembly/source and tools listings from Bjars.com and the Mini-Dig, maintaining a local copy of all the source files and noting their completeness. Now anyone who finishes a disassembly would be able to go in and update/add to the list as they're completed. Maintaining a list of projects? This is currently done with the VES wiki, but it would also be possible to maintain a page for listing current works-in-progress, projects, finished homebrews, &c. This is just an experiment, but I thought it might be worth a shot. I'm going to continue updating the documentation as I find the time/work on my own games. If you're interested in contributing to the wiki, please do! And any suggestions you might have on expanding/improving the site are also appreciated.
  5. Sorry for the downtime. The VESWiki is now permanently relocated to its new address here: http://classicdev.org/VES/ Enjoy!
  6. Seems so, too bad. I'll see if I can get hold of Tim... I've let the domain temporarily lapse. I'll get it up (somewhere) ASAP, thanks for pointing it out.
  7. If only there were enough time for logic. :/ From the middle of a line to the beginning of the next is something like (with VDELP0, VDELBL, and an asymmetrical playfield): ; 2nd line tail lda #(ballbit) sta ENABL lda #(p0 data) sta GRP0 lda #(pf0 data) sta PF0 ; PF0 now invisible lda #(pf1 data) sta PF1 ; PF1 now invisible ldx #(bg color) ldy #(pf color) lda #(p0 color) sta HMOVE sta COLUP0 ; 2nd line start lda #(p1 color) sta COLUP1 stx COLUBK sty COLUPF lda #(p1 data) sta GRP1 ; 16 cycles So cramming in as much as possible in the beginning of a line, that leaves about 6 cycles free (or 9 cycles if I HMOVE each line, but). One possibility is to drop in the ENAM0 and ENAM1 with a register of a known condition (the generator knows COLUP1 will have D1 set, so drop it there), but an extra LDA is required in the off chance that all of them has it set. Alternately, the generator could just lose a bit of luminosity control on their colors, but that's cheating. But all that aside, I think an improved TIA painter is a great idea. Probably a lot more useful than this is, and should be easy to convert over. In fact, if anyone has ideas for 2600 code generation tools, I would be glad to help.
  8. Some technical notes. (You can skip this if you're just interested in the program!) This program is not meant to generate tight, kernal-friendly code, but instead take full advantage of every register and graphics option the 2600 has (creativity over the technical aspect, so to speak). Instead of generating data, it actually generates 8 lines of code, including all HMOVE, graphics-loading, and color register setting. While this wouldn't be practical for a real game, by now, ROM size has grown exponentially, while the limits of the 2600 have stayed the same; if one could take advantage of ROM space to improve graphics, then it seems a worthwhile tradeoff. The row is 8 pixels high, so you would need 12 of them to make a full screen. You can try--the generated row is about 600, 700 bytes, and there's little room for bankswitching. Optimizations could improve that (there's better ways to waste 50 cycles than 25 NOPs). Generating code in RAM would be even better; maybe once the generation has been standardized. If you're interested in how the code is generated, go to the "chrome\content\rowEditor.js" file and find the exportRow() function. The graphics get messed up at high pixel values cause there is an HMOVE butting in on the RESxxs. Fixable, but difficult. Missiles are another story. Getting an LDA and two STAs in after a WSYNC is painful enough, but can somebody tell me why RESM0 an RESM1 use bit D1, not D0? I could totally take advantage of D0 on the color byte being useless. -.- If somebody finds me an illegal opcode which does ROL, STA in three cycles (or even INC, STA), please tell me. Then again, there's also no time to RESMx the missiles anyway, so it's almost moot. NUSIZ and CTRLPF could be set during the first lines (since no sprites can be displayed there anyway) but it'd be cooler if they could be set on every line (for variable-size sprites). Doesn't seem feasible, though. HMOVE can be set on each line. However, sprites could only move even more left, so it's kinda limited. A future version might do HMOVE on each line, use the HBLANK lines for extra cycle time, and allow per-line sprite movement. If that'd be at all useful.
  9. Small side project of mine. :] Allows you to edit a row of graphics in an interactive GUI, and generates a complete assembly file that you can compile and run. Download it and give it a try. Instructions: Open/Save opens and saves a row file. When you're finished, hit Export Code to generate source. Just play around with the rest, you'll figure it out. VESRE v0.1 (Windows) 8.8 mb; works out of the box VESRE v0.1 (Linux) 14.8 kb; requires "xulrunner" package NEEDS: - DASM - an emulator (or a real 2600!) TODO: - Fix known bug, high X values screw up position of sprites - Allow editing of multiple rows (if you had that much ROM space!) - Allow editing of missiles - Allow setting other things (NUSIZ, CTRLPF, &c.) - Get values from RAM (game potential!)
  10. Future of homebrews? You'll at least be seeing a Channel F homebrew, once I get around to putting time into it...
  11. That'd be nice to have... I've been thinking of burning a Garfield cart. Thinking of tracing one of the mockups if I couldn't find anything in higher quality... I have a question: is it just me, or is the first 8k of the Garfield ROM corrupted? Instead of being filled with $00, it's filled with $80, and no byte in the entire 8k is < $80. Plus, the code doesn't actually make sense. I came across this trying to decompile the ROM... the first 8k is never accessed, though, so it's not obvious.
  12. Looking over it a bit, it can easily be improved, and I had the JSR/RTS address wrong. 18 bytes, no RAM needed: jsr SwapBank1 .word SomeRoutine-1 SwapBank1: ; routine address is located at the return address (stack+1) tsx inc $02,x ; shift routine adress pointer to low byte ($ff will roll over!) lda ($01,x) ; load low byte of routine address tay ; store it in y inc $02,x ; shift routine adress pointer to high byte lda ($01,x) ; load high byte of routine address sta ($02,x) ; rewrite the new routine address tya ; over the older return address sta ($01,x) jmp LFFF7 ; switch banks LFFF7: rts
  13. Very nice! It's elegant, it's simple... and it works! Expanding a little on that, if you use the routine a lot, then maybe using lda, pha twice to get the address would be overkill. I'm not sure if this would even work, but it might: jsr SwapBank1 .word SomeRoutine SwapBank1: ; return address is at stack+1 tsx inx lda ($00,x) sta temp1 inc $01,x lda ($00,x) sta temp2 inx txs lda temp1 pha lda temp2 pha jmp LFFF7 LFFF7: rts[/quote] At the expense of a 23-byte routine, you can save four bytes every time you switch banks, and use a more elegant syntax. It could probably be expanded to check the higher bits to see which bank to switch to ($0xxx could be bank 0, $1xxx bank 1, etc.) You'd need to switch banks several times in the code in order to save space, but maybe there's a way the code could be simplified... just a thought, anyway.
  14. I say that if you have the capablility to make a good looking port, then it's be great if you took advantage of it. I vote for the realistic art style, though having both would be even better, if you can manage.
×
×
  • Create New...