Mr SQL

Thanks Tom, I've updated the bin. It looks much better with that column not breaking! The bug was in the expander BITShifter.bin My algorythms are very efficient but I need to optimse them further to avoid using a whole frame - one thing I can't workaround with the source table in ROM is modifying the scrolling large play area on the fly; a large play area the size of the demo can actually reside entirely in superchip RAM (the 100 pixel wide 10 row table is only 120 bytes) to keep it malleable but larger play areas double that size (the 256 byte tables) are limited to display only - good for mazes and scrolling backgrounds that can't be changed. How do you get around these limitations modifying your large play area in BoulderDash - RAM beyond SARA like the SuperCharger?

Thanks RevEng! - wow the difference is night and day in Stella, thanks again! I'm almost tempted not to optimise it.

All of the tables used in our tiling engine are auto-generated with macros, so that the size could be changed without having to worry about things The actual code is... NEWRAMBANK BANK_BOARD ; Now the interesting 'BOARD' -- which in reality is a free-form system of M*N ; rows and columns. We need to reserve enough RAM for the board's entirety, but ; don't really care much how it overlaps the 1K bank limit. The code accessing ; the board *MUST* calculate and take account of the correct RAM bank to switch ; when accessing. ; The system is fairly free-form, in that it rearranges the memory and tables ; automatically based on the sizes set in these constants. The board may overlay ; MULTIPLE banks -- just as long as any particular LINE does not cross a bank ; we're doing OK. ; NOTE: Assumption is that board lines CANNOT CROSS page boundaries. ; now fits into one single bank (if we don't reserve too much space for code) SIZE_BOARD_X = 40 SIZE_BOARD_Y = 22 ; have to precalculate it here, else DASM freaks out: .BOARD_SIZE SET 0 .BOARD_LOCATION SET 0 REPEAT SIZE_BOARD_Y IF >.BOARD_LOCATION != >(.BOARD_LOCATION + SIZE_BOARD_X-1) .BOARD_SIZE SET .BOARD_SIZE - .BOARD_LOCATION .BOARD_LOCATION SET .BOARD_LOCATION - <.BOARD_LOCATION + 256 .BOARD_SIZE SET .BOARD_SIZE + .BOARD_LOCATION ENDIF .BOARD_SIZE SET .BOARD_SIZE + SIZE_BOARD_X .BOARD_LOCATION SET .BOARD_LOCATION + SIZE_BOARD_X REPEND SIZE_BOARD = .BOARD_SIZE IF SIZE_BOARD > RAM_SIZE MULTI_BANK_BOARD = YES ELSE MULTI_BANK_BOARD = NO ; timings: [-..] ENDIF Board ds SIZE_BOARD ; Note, we can only access this in ; 1024 byte chunks, switching RAM ; banks as we go. In other words, ; this overlaps multiple banks! What this is essentially doing is making sure that we have a large array of lines, but also that none of those lines crosses a page boundary. We then refer to any particular line (y) by first looking up its start address and bank from a table, then indexing to retrieve the character number (x). Those lookup tables are... NEWBANK INITBANK .byte 0 ; to avoid extra cycle when accessing via BoardLineStartLO-1,y DEFINE_SUBROUTINE BoardLineStartLO ; Gives the start address (LO) of each board line .BOARD_LOCATION SET Board REPEAT SIZE_BOARD_Y IF >.BOARD_LOCATION != >(.BOARD_LOCATION + SIZE_BOARD_X-1) .BOARD_LOCATION SET .BOARD_LOCATION - <.BOARD_LOCATION + 256 ENDIF .byte <.BOARD_LOCATION .BOARD_LOCATION SET .BOARD_LOCATION + SIZE_BOARD_X REPEND CHECKPAGE BoardLineStartLO SIZE_BOARD = .BOARD_LOCATION-Board ; verify calculated value ;------------------------------------------------------------------------------ BoardLineStartHiR ; Gives the start address (HI) of each board line ; Note this caters for the memory wrapping when we go from bank to bank, as ; the board overlays multiple banks! .BOARD_LOCATION SET Board REPEAT SIZE_BOARD_Y IF >.BOARD_LOCATION != >(.BOARD_LOCATION + SIZE_BOARD_X-1) .BOARD_LOCATION SET .BOARD_LOCATION - <.BOARD_LOCATION + 256 ENDIF .byte >( .BOARD_LOCATION & $13FF ) ; cater for mirroring of memory images .BOARD_LOCATION SET .BOARD_LOCATION + SIZE_BOARD_X REPEND CHECKPAGE BoardLineStartHiR ;------------------------------------------------------------------------------ BoardLineStartHiW ; Gives the start address (HI) of each board line ; Note this caters for the memory wrapping when we go from bank to bank, as ; the board overlays multiple banks! .BOARD_LOCATION SET Board REPEAT SIZE_BOARD_Y IF >.BOARD_LOCATION != >(.BOARD_LOCATION + SIZE_BOARD_X-1) .BOARD_LOCATION SET .BOARD_LOCATION - <.BOARD_LOCATION + 256 ENDIF .byte >( ( .BOARD_LOCATION & $13FF ) + RAM_WRITE ) ; cater for mirroring of memory images .BOARD_LOCATION SET .BOARD_LOCATION + SIZE_BOARD_X REPEND CHECKPAGE BoardLineStartHiW ;------------------------------------------------------------------------------ IF MULTI_BANK_BOARD = YES BoardBank ENDIF ; Gives the RAM bank of the start of the board row for a given row. .BOARD_LOCATION SET Board - RAM_3E REPEAT SIZE_BOARD_Y IF >.BOARD_LOCATION != >(.BOARD_LOCATION + SIZE_BOARD_X-1) .BOARD_LOCATION SET .BOARD_LOCATION - <.BOARD_LOCATION + 256 ENDIF IF MULTI_BANK_BOARD = YES .byte BANK_BOARD + (.BOARD_LOCATION / RAM_SIZE) ; actual bank # ENDIF .BOARD_LOCATION SET .BOARD_LOCATION + SIZE_BOARD_X ; note, we CANNOT cross a page boundary within a row REPEND IF MULTI_BANK_BOARD = YES CHECKPAGE BoardBank ENDIF As you can see, we make fairly extensive use of comments, macros and auto-calculation here. The short answer to your question is that we do not allow rows to cross page boundaries, so we can get efficient access. Cheers A Andrew, I follow what you're saying on the precalculations, look up tables and page boundries - very cool design, the performance is tremendous! I like your queue implementation as well for throttling the time intensive events that pile up! My playfield image expander and bitshifter engines crunch the 6502 quite a bit as Tom pointed out but I've got them working and now optimising to fit them in the blanks. Here is the thread with the details and a bin demo if you or Tom would like to take a look and discuss (either here or there): http://www.atariage.com/forums/topic/200972-tile-based-scrolling-and-expanding-engines/

Twin Engines for playfield bitstream expansion and scrolling: I've had a number of 2600 games in mind I'd like to build that could use an expanding and scolling tile/virtual pixel engine and seeing the impressive scrolling engine in BoulderDash inspired me to build these; my scrolling and expanding engines are respectively a bit shifter and a bit expander. The 2600's unique architecture threw up a couple of obstacles along the way thus these twin engines complement each others functionality - the bit expander can function stand alone but the bit shifter requires it's assistance to work Functionality: This tile based scolling engine can take a very wide right-ways-up playfield bitmap and pan across the image while silmutaneously expanding the image in a 2:1 ratio so that 20 virtual pixels span the screen, it can scroll up and down too depending upon the height of the bitmap but I'm just side scrolling in the demo. In the pic of the panoramic bitstream below, note the contiguity of the bit pattern with no gaps or flip-flops after the first four spacers left over from the initial expander which can run either as a stand alone engine (the expander can static screens) or as a component of the bit slider: (panoramic WYSIWYG bitstream the bitshifter slides across) World size specs: Because the bitstream is expanded 2:1, a large virtual world up to 10 screens wide (200 pixels) can be easily stored in a single 256 byte table. Combinations are also possible such as a virtual world two screens high and five screens across. Demo: BITShifter.bin The demo pans across a virtual world 5 screens long; the bitmap shown above in a 120 byte table. Here is the bin, it's a bit annoying in Stella because I halved the framerate for cycles but it looks OK on the real hardware (why can't Stella handle skipped frames as good as a Television? I thought it had phospher simulation). Optimisations: I am now optimising these engines to fit within the blanks by taking just a bit of the screen display for more of a DVD style view (still 20x10) with squarer pixels where I won't have to halve the framerate.

You must love the Model I, then! I feel like there were a few games that used the semigraphics modes...ah, here's one! I actually have Cave Hunter on a cart for the Dragon. Protector II might have been the best semi-graphics game for the CoCo. thegoldenband, Fry-Draca looks awesome! I've never seen that one but that's exactly what I'm talking about. That game is a perfect example of the colourful retro lost with the CoCo3. JamesD, right on, great examples! Here's a screenshot of the 64x32 semigraphics mode (the only one the GIME retained) being used inside the directory for one of my text adventures - I wrote a semigraphics "paint" program for drawing 20x32 semigraphics on the disk directory: yell0w_lanter, Dino Wars is a fun game, the roar is awesome

I owned a Coco I (16K ECB, upgraded to 64K in 1984) from 1982 through about 1990 and I don't recall ever having seen any commercial software that used the semigraphics mode, other than one educational program. For that matter, I don't remember ever seeing those modes discussed any articles in Hot Coco. (Rainbow was not easily or consistently available where I lived.) I think that part of the lack of use was the very minimal documentation available. Other than the brief (and cryptic) coverage at the back of the Introduction to Color BASIC manual, the only place I ever recall seeing information about the semigraphics modes was in one of Bill Barden's books abut the Coco. Back on topic, one of my favourite games for the Coco, not yet mentioned, was Shamus. I never manged to get too far into it, but the graphics were quite impressive. jhd, I agree that was a great game! I still have Barden's book on 6809 Assembly and EDTASM+ on my bookshelf I think the GIME's 320x192 16 colour mode did not offer much over the 256x192 artifact colour mode; instead of a square pixel and more resolution you just get a bigger rectangle pixel. They're pretty close visually. IMO semigraphics are a 10 on the retro meter; the more semigraphics modes a system has the more retro coolness it has

From you description it seems pretty elaborated. But I don't think it is feasible, because of too many CPU cycles required. So before you invest too much time into planning, maybe you should do some CPU cycle calculations. Tom, good point, it's pretty tight but I think I can optimize it more. Here's a pic of the engine rendering a 20 pixel grid right ways up on the playfield by mapping 3 byte rows (1 bit per pixel) into 6 byte rows (2 bits per pixel) of RAM for the playfield to display; a few of the 3 byte rows are shown on the inset: I'm plannig to extend this bitmap as much as desired (blue arrow) and use a bit index as the literal Y value to float a 3 byte section anywhere within the row to scroll the image back and forth - the vertical blank section at the bottom where I've got some more time seems like a good place to precalc it and fill 1/2 the RAM buffer reserved for the playfield with the bit shifted 3 byte target rows to build the playfield with and then just point the engine there without changing the routine so it can expand it to six bytes

Andrew and Tom, that's an awesome engine you've built in BoulderDash! I'm building a tile based scrolling engine that reads a 3 byte wide table (30 bytes if there is no vertical scrolling done) into a 6 byte wide RAM buffer (60 bytes) that gets loaded into the playfield; each bit of the source bytes gets doubled to create a 20x10 board of rectangular tiles; it also mirrors the bits as required in the RAM buffer so the images are depicted correctly in the 3 byte wide source table. I'm working on the side scrolling aspect now and plan to implement it using a bit index and a 12 byte wide source table: the bit index allows me to start building the RAM playfield at any point - I'm still building it out of 3 bytes per row I just slide my bit pointer around within the the 12 byte wide ROW. A 3 byte wide screen (20 bits) makes the play area four screen widths worth of scrolling which is fine for the game I have in mind; I want the play area to also scroll two screens vertically so that puts me at 240 bytes which I can just fit it in one table. I prefer not to set up multiple boundries for the bit index as I would using mutiple 3 byte source image tables as screen-wide (20 virtual Pixel) vertical strip sections of the larger play area; With a 10x8 tile grid I imagine you are also sliding a bit index across a larger row in it's entirety; could you fit a complete BD tile world in a 256 byte table given the large tile size or did you split the worlds across tables on the Y axis for more room so as to leave row size intact for speed?

loon, sure the example is from CityScape, I've shared the source code here: http://www.atariage.com/forums/topic/187460-cityscape-new-2600-game/ I have an idea why the block isn't compiling for you; try setting the option for a 31 pfpixel high screen (superchip) instead of 11 pfpixels: set romsize 8kSC const pfres=32

I'm not ignoring you dawg I'm behind on my own coding (my own fault). Hopefully someone will whip up or link to a good example. esplonky, here is a block of code I think you may enjoy The routine draws several layers of random structures over one another to create a random cityscape. v=5 rem overlay 5 drawings of random structures, try setting it to 1 to see the difference for w=1 to v q = rand: q= q / 8 rem q = 32 - q if q < 5 then q = 5 if q >26 then q = 6 t= rand: t= t/8 u = rand: u= u/40 + t rem can't get that last column... so don't set it if u>29 then u=29 if t>29 then t=29 for m = t to u for n = q to 31 rem goes to 31 pfpixel m n on next next next

Ah, sorry yell0w_lantern, it's actually "pclear 1"! JamesD is correct, you cannot clear away all the graphics memory through Basic so pclear 0 is not allowed but pclear 1 should free up another 4K.

Looks like it's ?PEEK(116) And I get 127 so it must be 32k. Thanks! [EDIT] You got this in as I was typing. I went back and tried "clear 0" but only got a little over 25k. The model number is 263026 - an early model 2 from what I have read. yell0w_lantern, you only freed up 200 bytes with clear 0! Type "pclear 0" and you will free another 4K There really are no 32k CoCo's because they all have 64k of RAM in them A jumper was needed on some models to enable the other bank but if your uncle put in a composite mod in it's probably enabled as 64k if it was "32k".

It returns 24871; I'm assuming that's in bytes. So I'm guessing he either had less and hardware-hacked in more or there's been some damage and a higher RAM count was lost. yell0w_lantern, that's fine you have a 64k CoCo2! type pclear 0 first and you'll get 29 out of 32k; the other 32k is mapped to ROM but various tricks and remapping can free up up to 42k of RAM for Basic as per the Dragon's configuration. IMO the CoCo 1/2 is even better than the CoCo3 because it supports higher resolution semigraphics modes that are awesome for games; the 3 only supports 64x32 semigraphis over text. Potatohead, I agree Maddness and the Minotaur was excellent, also loved sands of egypt. I would add Whirly Bird Run and Cybernoid (CoCo and CoCo 2 only, hires semigraphics) to the list of great games; TimeBandit pretty much takes the cake on optimized 6809 performace. And Grabber - this game is great fun and does complex multivoice music and graphics at the same time. Unforturtunately my only working CoCo is a CoCo3; 512k with PC keyboard adapter, I've got a 5.25" drive in one of my PC workstations that can read the floppies so transferring data is no problem and I don't have a solid state device like the UIEC for my C64. Gauntlet for the CoCo 3 is pretty awesome, much like the Genesis verison but you need the 512k upgrade to play it, other than that most of the CoCo I and II games are better. Just my opinion but I can't deal with the GIME losing the VDG's old semigraphics modes; it's not really compatible then, is it? I think the lost semigraphics modes are gold, they are lightning fast and they are like artifacting - you multiply the bit plane for nothing, materialising free RAM to pull colours straight from the ether. Semigraphics counted for a lot when CoCo's had 4k and IMO they bring tons of retro coolness to the gaming table today; if I write a new CoCo game today you can bet it will only run on the I & II because I'm going to use semigraphics modes like in my recent Atari 2600 game BREAKANOID (uses the playfield to build the player, the ball and the bricks) I think the CoCo3 is in the same category as the Commodre128; overshadowed by a more interesting machine it's closely compatible with and I'd rather have the more interesting machine.

This is great! Here's a gem from 92 looking at the the emergence of 3D gaming and what seemed to be impossible textured polygons on a 286 PC: People have been curious about the new PC game Wolfenstein 3D. We have wondered how the speed of the "real" 3D effect was accomplished. This explanation came off the usenet from someone at SGI: Wolfenstein 3D cheats. It's not really drawing 3D textured polygons. What it's doing is sort of a cross between ray tracing and bitmap decimation. For each column of pixels on the screen, they shoot a ray out and find which wall it intersects with. From the length of the ray, they know the top and bottom coordinates of the wall in screen space, and from the intersection point of the ray with the wall, they know which column to use from that wall's texture. By decimating or duplicating pixels from that column, they resize it to be the correct height for the screen.

That's Color Computer. Since it was made by a Texas-based company, it has to be. LOL jmetal88! It was more like the early PC with many different companies manufacturing it with a somewhat incompatible BIOS but otherwise the same parts and Microsoft's Extended Colour Basic. Some mfr's like Dragon Data probably spelt it colour in all their advertisements

The entire NitrOS-9 library? The OS-9 library is impressive but who cares about that; a 6809 in an Atari offers the potential for awesome games! That page compared an Atari 800 to an Apple II but the independant sound and graphics processor chips made Atari 800 games lightyears ahead of anything Apple. This is an important concept because the 6809 in the Colour Computer had enough power to also handle graphics and sound processing in software quite well. Assisted by Atari hardware I think Genesis quality games could be developed; it's as if Boisey has created a CoCo3 with more powerful graphics, and sound

Waggie, good observation, that is exactly the reason I was using the mouse - you need to be able to respond just as fast in all directions but when using the arrow keys one finger shares up and down while left and right each have their own finger, this results in latency going up and down. There's no direction specific latency with the mouse, it's just hard to use it as a controller. This game needs to be played with the Joystick or you have to get a finger on each arrow key so each direction can have the same response time. RT don't slow it down, I think SA is fantastic - fast is the coolness of Atari

Seaweed Assault is loads of fun, awesome game RT! I can rack up hundreds of points playing on the real hardware with a sega d-pad or Atari Joystick but it's hard to break 100 with Stella using the mouse:

JohhnyRockets, those are two great platforms to code for but the 2600 is the more challenging because there is no screen memory. There's a Tiny-BASIC compiler out for the 2600 you may want to also try that's very good - Batari Basic. Nukey, that book looks like an excellent reference for beginners; could you point out one of those spots?

X2 GroovyBee, this is a great discussion topic revolutionika! Multicarts open up new possibilities for playing and buying games in ROM format that we are going to see more of; games that are either more ideal for the multicart or expressly designed to take advantage of it's expanded features. I've released BREAKANOID in ROM format for the Atari 2600 as a series of four game ROM's with the option to put one of them on cart, but the series is designed for the Harmony and comes with a Level Editor for windows that lets you build additional game ROM's; these aspects of the release have influenced more than one gamer to also buy a Harmony cart. And as far as piracy it's a minimal issue compared to the 80's just as the market is minimal; fans and collectors support homebrew development

Wow, those zx81 tunes are awesome yerzmyey! Great work! I like all of your chiptunes music and the selection of machines you created them with - really fantastic! :)

I think you're judging the programmers a little harshly there. The development tools were of poor quality, the released hardware was buggy to the point of being crippled and a lot of the programmers were start ups or one man teams. Even Id Software struggled to get Doom out of the door in a timley fashion, even then it was broken in parts. I think high voltage has a good point. There's a lot of variance based on which CPU's the development teams were able to harness and how well; I'm quite impressed by the hardware, the Jag has potential Curious why you say the development tools were poor; I would imagine there were compilers, assemblers and libraries of cool routines for both that came in a can like spam just like in the 80's as well as some 3-D modeling and rendering tools and engines (very 90's). Anyone have a list of what was in the dev kit Atari released to the game studios?

maiki, I have no problems using a Genesis pad with my 64; what happens when you try it with yours?

WSGEXE, I agree the carts are fun to collect and that the sega d-pad rocks; why do you consider 30 year old games for a legacy platform to be stolen? IMO it's pretty cool that retro gamers are enjoying my video games from the 80's and I think many other game developers feel the same way; generally we're not selling these games anymore so it's just about fun Something to think about, the Harmony is also a platform expander for the 2600 just like the Starpath SuperCharger and likewise, there are new 2600 games that have been developed for the Harmony that take advantage of it's extra capabilities. Open your mind to the possiblities - there are soft releases like BREAKANOID that are designed specifically for the Harmony. BREAKANOID comes with four different game ROM's and a level editor for Windows that lets you design new game ROM's. There's an option for collectors to get a stand alone cart but the point is it's a soft release designed for maximum fun with the Harmony. The Harmony also lets you enjoy the playable demo versions of many fantastic new homebrews - if you get a Harmony think of all the great games you can enjoy for free on the real hardware!

There are three wires you'll need to connect from the midi cable; one is for the ground which is the outer wire for both the audio and the video RCA plugs and the other two are for the video and audio signals which go to the central wires for the RCA plugs.