Kurt_Woloch

Here are my times for this past week (May 7th through 13th) on classic systems: Android Phone: Crazy Taxi: City Rush - 103 min. in 7 sessions Toon Blast - 84 min. in 2 sessions I've continued to play Crazy Taxi: City Rush on Android. By now, I managed to buy a 2nd car in the Hills district and rent it out. I'm now doing it rather chaotically, at the moment completing the medal missions of the first (Downtown) district while at the same time upgrading and renting out some of my cars. I've also tried out a new game on my phone, Toon Blast. This is a puzzle game where you have to take out groups of tiles having the same color. It was easy going for quite a few levels, but now I'm stuck on a level I just can't complete, so I think I'll give up on it again.

Here are my times for this past week (May 7th through 13th) on classic systems: Intellivision: Auto Racing - 14 min. in 4 sessions The ony classic game I've played this week is Auto Racing on the Intellivision where I continued to assemble a map of it.

Sorry for hijacking or reviving yet another thread, but I've been reading up on the Cassette Vision lately, and I see some facts about it scattered on various internet sites which, if brought together, could lead to a deeper understanding of the system and its cartridges... First, while the Super Cassette Vision has a MAME driver for it, the Cassette Vision doesn't. The primary reason being that the console itself doesn't contain much hardware, rather each cartridge has a special chip on it which contains all ROM and RAM and other circuitry needed for this game. But this chip on each cartridge is actually part of a chip family which, to my understanding, still could be emulated if properly understood. I've read through the following interview with one of the designers of the Cassette Vision, Masayuki Horie, and it has quite a bit of useful info on it: http://shmuplations.com/epoch/ The Cassette Vision cartrdges all use a variant of a NEC microcontroller which was first used in the dedicated Epoch consoles "TV Vader" and "TV Baseball". The chips are called uPD77X, with the part after the 77 changing from game to game... each game had its own variant. For instance, TV Vader's variant was called D774C (as written on top of the chip). This can be seen here: http://discreteconsoles.blogspot.co.at/2015/10/nec-upd774c.html All the games had similar graphics, so I guess the graphics capabilities didn't change fundamentally. Judging from the screenshots and videos, I'd guess the possible resolution is about 56 x 56 to 60 x 60 pixels, though not all of it may be visible on screen, similar to the Channel F. According to the interview mentioned above, the screen is entirely made up of sprites, and there are 21 of them in total. From the screenshots, it can be seen that the sprites are probably 8x8 pixels in 1 color out of 8 or 16, but there seems to be an ability to draw them as diagonals, but doing so exposes a transparency glitch where black triangles appear at the left or right of sprites drawn this way, filling a square halfway made up by the diagonal instead of the background being transparent. Now according to the interview above, the microcontroller internally uses a 48-bit architecture, so the instruction format is probably a strange one. But there is one variant of it that was more exposed, the D779C 300. This one wasn't used in any Epoch Cassette Vision cartridge, but in the Hanimex HMG-7900 console. The chip is called "programmable", but according to the pinout, it doesn't exactly expose address and data busses like real CPU's do. There is a discussion about that console there: http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=103713 According to that thread, the Hanimex console doesn't have any video memory... which actually doesn't surprise me since I think all the video "memory" is contained in the D779C chip, and I think it's rather a memory map where every location means a specific thing. This would be similar to the TIA of the Atari 2600 and the video chips used in the Interton VC-4000 and the Odyssey^2. What they have in common is that they all have various memory locations (at most 256 of them) controlling the display, but they have to be externally fed with data because they don't access external RAM by themselves. Instead what they display is entirely defined by those on-chip memory locations. On the Hanimex console though, it seems that the cartridges actually contain the CPU (an 8049 this time) which sends commands to the D779C built into the console. Which commands I don't know since I neither have any of the binaries for the D779C (which then could be disassembled) nor any cartridges. But by carefully tracing the disassembly and figuring out which commands get sent, one could at least figure out what each command does, and further, if it's actually setting register values in the D779C, figure out what the respective registers do. Sean Riddle seems to have also decapped and visually dumped the Cassette Vision chip for "Monster Mansion", which is a D777C 009 and actually contains two areas of ROM. I suspect one area might be the code, and another might be the graphics which are read separately (similar to CPU and CHR ROM's on NES cartridges). On the Hanimex console meanwhile, I guess the on-board 8049 in the cartridges run the game and access the D779C via Port 1 (bit 7 for clock, the other bits send commands) and the controllers via Port 2, which also receives acknowlegdes from the D779C. The commands don't seem to be sent very often according to the logic analyses (at most 1 command per scanline). So maybe disassembling the code of the Hanimex games could be the key to knowing how the graphics work, and knowing that could make the emulation of the other custom chips for the Cassette Vision feasible.

Here are my times for this past week (April 30th through May 6th) on modern games... Android: Crazy Taxi: City Rush - 72 min. in 7 sessions Arcade: Dolphin Star - 6 min. in 2 sessions Gaelco Championship Tuning Race - 6 min. in 2 sessions The world's biggest Pac-Man - 6 min. in 2 sessions This week I played quite an assortment of games. I've been to multiple arcades as well, playing both classic and modern games. Actually, I was in search for an arcade cabinat that moved the player, and finally I found one in the game Gaelco Championship Tuning Race, although only one of the two cabinets there actually moved. I suspect there were other arcade machines there which originally moved, but the moving mechanism was broken. I also played Dolphin Star again, and the two sessions are literally here because you sit down in the saddle and are rocked. Also I played The world's biggest Pac-Man, which is a new machine with a giant screen composed of 288x224 individual LED's and over a meter high. Pac-Man stays somewhat true to the original, but has been updated by including a 2-player competitive mode. Also, if Pac-Man dies, the ghosts keep moving while Pac-Man restarts, and the fruit traverse the maze like they do in Ms. Pac-Man. You also get bonus points at the end of each round, and you get to input your name before the first intermission starts (maybe it's actually at the end of the round that first puts you in the high score table). On my first try, I played pretty badly and didn't survive the 2nd round, but the 2nd play was better and lasted until the 3rd round, which got me to #4 in the high score list. The cabinet also includes Galaga which hasn't been updated that much, but I didn't try that one. In Crazy Taxi: City Rush, I managed to complete all upgrades on my car, and now I'm working to buy a second car which I then can rent out and upgrade.

Here are my times for this past week (April 30th through May 6th) on classic games... Arcade: Daytona USA 2 - 2 min. Galaga - 15 min. Pac & Pal - 6 min. Scud Racer - 2 min. Channel F: Alien Invasion - 22 min. in 2 sessions Handheld: Ms. Pac-Man (Coleco) - 8 min. Intellivision: Auto Racing - 39 min. in 4 sessions MSX: Bomberman - 27 min. GP World - 6 min. Pac-Man - 3 min. Sharp X68000: Kikori No Yosaku - 43 min. This week I played quite an assortment of games. I've been to multiple arcades as well, playing both classic and modern games. I consider Daytona USA 2 and Scud Racer classic games because they were released before the year 2000. Actually, I was in search for an arcade cabinet that moves the player, and finally I found one in the game Gaelco Championship Tuning Race, although only one of the two cabinets there actually moved. I suspect there were other arcade machines there which originally moved, but the moving mechanism was broken. Also I played The world's biggest Pac-Man, which is a new machine with a giant screen composed of 288x224 individual LED's and over a meter high. Pac-Man stays somewhat true to the original, but has been somewhat updated (more about that in the Modern Gaming tracker). The cabinet also includes Galaga which hasn't been updated that much, but I didn't try that one. I then played the original Galaga in order to see how good I would have been at it, and didn't fare as well as in Pac-Man, but still after a few attempts I managed to get into the 3rd attack wave (through the first challenging stage). I also briefly replayed Pac & Pal. On the Channel F, after attempting to write something like Pole Position which suffers from a low framerate, I played Alien Invasion, which is a pretty fluid and playable version of Space Invaders. They managed to let it run at a pretty constant frame rate, partially by not updating all of the score at once, but only one digit per frame. I also played the handheld version of Ms. Pac-Man by Coleco, but the emulation in MESS doesn't quite work since Ms. Pac-Man once somehow got into a part of the maze which should be inaccessible, and in another game, she disappeared completely. I also briefly played the Pac-Man version on the MSX system after playing GP World on it (trying to recreate Fuji Speedway on its editor) and a session of Bomberman, which started out on the MSX and other 8-bit computers back in 1983. Also, I played Kikori No Yosaku on the Sharp X68000, which is a port of the signature game of the Epoch Cassette Vision which is still unemulated because it has the CPU, display processor and memory on each cartridge, presumably in a single chip, similar to the Coleco Telstar. Therefore I think there was one pinball game which appeared on both systems using the same chip. Finally, I've completed the map of the actual tracks of Auto Racing on the Intellivision, but I'm still working on the off-track areas.

OK, I tried to squeeze out a bit of speed now, by shaving off a few pixels on the left (and adding one to the right to fill the previously visible gap). The sky drawing routine is still preliminary, so that also may take away more time than necessary for what's actually being displayed. I've now timed the routines I have and found that I'm already taking far more than the (probably) 64 yS which the ports have to be left alone after the "strobe" before changing any output value, so I eliminated the delay loop during road drawing and shortened it during sky drawing, which should speed up things a bit. Still there's not too much you can do... there needs to be this delay between writing of each pixel, and there's no way to get around that other than updating a smaller area of the screen in general. But that would take some logic to figure out what has actually been changed and what stays the same (and doesn't need to be overwritten). And this would need more complicated code, and also more RAM. Right now, I'm only operating on the 64 registers built into the CPU because the stock Channel F doesn't have more readable RAM than that. This means only storing what's absolutely necessary. For instance, the displacement value of each row (which makes up the curving of the road) is only calculated for this row and then discarded once the row has been drawn. But this doesn't matter as long as I'm overwriting the graphics with the next frame anyway. The slowness also comes from the fact that on the Channel F you have to write the screen pixel per pixel, and you don't have hardware sprites. On other 8-bit computers and consoles with games like this, typically some trickery is being done like simply manipulating the display list for each scanline so that the graphics don't have to be written to a bitmap, and the road objects are displayed by hardware sprites, at least some of them. Thus you can find a pretty fast version of Pole Position on the C-64 (but the curving of the road doesn't look pretty there) and the Atari 800. Even better is "Street Surfer" by Mastertronic on the C-64, which to me seems to have the fastest road drawing code which still gives a reasonable 3D impression. On the other hand, have you seen the TI-99 version of Pole Position by Atarisoft? Here, while the player car moves smoothly left and right, the enemy cars and center line only update at about 4 fps, and the curving of the road itself often falls down to 1 FPS as well. And on the Channel F, to update all the visible area of the screen you need at least 0.4 seconds, and there's no way around that other than only changing the pallettes of the lines. But to make up for that, you get a nice overscan picture because the Channel F's video memory covers all the area the beam can display. Personally, I'm aiming at about 2 FPS. Whether the game is playable at the rate remains to be seen... Anyway, here's an updated version which runs a bit faster. game.bin game.asm

Here's another iteration... this time I refined the sequence of curves and slopes a bit, and the player car is now visible at the bottom of the screen. game.asm game.bin

Here's another iteration of my test code. I figured that it wouldn't take much more time to have the track also bend up- and downwards instead of only left and right. I've also somewhat swapped directions, so now the curves and slopes go into the same directions as on the original track, and also occur at roughly the same point, though some curves don't look as sharp as they should, while some hills are vastly exxagerated compared to the real world. Oh, there's now also some piece of sky, but this should definitely get more refined. game.bin game.asm

Here are my times for this past week (April 23th through 29th) on modern systems... Android: Crazy Taxi: City Rush - 73 min. in 7 sessions I continued to play "Crazy Taxi: City Rush" even after making all the main missions, because I've still got some more missions to go until the platinum medal in the Hills district.

Here are my times for this past week (April 23th through 29th) on classic systems... Intellivision: Auto Racing - 38 min. in 5 sessions On classic systems, I continued to play Auto Racing in order to map it out. Other than that, I programmed something for the Channel F; a system I've never programmed before, although I did write something for the Video Brain which has got the same F8 CPU. See the thread in the Programming forum...

Hi everyone! In another thread, I've posted a programming test of mine for the Channel F which basically draws a road with meadow on the left and right (stylized). Meanwhile I've developed it a bit further, and now the road is animated. Still no game or sound though, and you'll have to wait about 10 seconds until the road starts moving. What I'm thinking of is some sort of 3D car racing game resembling Pole Position. I've attached the current binary, as well as the current version of the source code which assembles in DASM. game.asm game.bin As you can see, I've taken a slightly different approach to the usual Channel F games which all work by drawing tiles or sprites on screen and erasing them again. In contrast to that, I'm drawing the road line-by-line, starting at the bottom up to the horizon. What I'm planning is to draw the sprites along with the background, that is, before each pixel gets drawn, it's decided whether it belongs to a sprite or to the background. The reasoning behind this is that on the Channel F, there needs to be a delay between two pixel writes, so the CPU, instead of wasting time, might as well spend the time figuring out what the next pixel will be. Right now there still is a delay loop after each pixel because drawing the road alone doesn't eat enough time. The question is, how much time do we need in between writes? I tried to figure it out by the delay loops normally used, and my guess is that the system is able to write one pixel for each on-screen scanline to RAM, that is, about every 64 microseconds, or in other words, there is a "window" every 64 yS where a pixel will be written to RAM if it has been strobed by then. The question now is what's affected by the delay. I guess the delay is there so that the necessary data stays on the ports for long enough after the CPU has strobed the write. This would mean that after strobing the write, 64 yS should pass before any data on the port gets changed. Or is this not the case, and there is some data being latched so after strobing the write, you can already change the data as long as you don't strobe another write? It has been written in the Veswiki that if you write the pixels too fast, gaps may occur. But how fast is too fast? And which timing counts? I've just timed the drawchar routine in the BIOS which is basically used to draw everything there, and according to the MESS debugger, at least 246 cycles pass from one write to the next, while a scanline takes roughly 458 cycles, so that would be closer to two writes per scanline... if the debugger is right. However, according to the debugger, there are 4 times as many cycles needed as is given in the opcode table in the Veswiki, which is understandable to me. I guess the cycles in the MAME debugger relate to clock cycles with the clock being 2 MHz for the early PAL machine, while the opcode table refers to machine cycles being 4 times as long (otherwise there couldn't be half-cycles needed by some instructions). This would mean that actually, the 246 cycles from one write to the next would be 123 microseconds. From the strobe off to the next port write, there's a time span of 192 cycles, which would be 96 microseconds or 1.5 scanlines. The delay loop alone wastes 80 cycles or 40 microseconds. In contrast to that, my road drawing code currently spends about 218 cycles (109 microseconds) per pixel, but has the port writes as close to each other as possible so that there are still 166 cycles or 83 microseconds from releasing the strobe to the next setting of data. Does anyone have any data about this?

OK, thank you for the heads up. And sorry for partially hijacking this thread. I will start my own now concerning my progress and a few more programming questions...

OK, now I've got the compiler to work as well. Here are some important bits that shouldn't miss: processor f8 org $800 cartridgeStart: .byte $55, $2B ; cartridge header ;here is where the actual code comes in org $ff0 signature: .byte "·K.Woloch· 2018" This will set the correct processor type. The next org command will let the binary start at $0800, which is where ROM starts on the Channel F. Then we have the cartridge header as the first two bytes. The Channel F checks this on startup (after clearing all registers) and only if it's correct, starts execution at $0802. The org $ff0 command places the last bytes given at $0ff0, which is where the cartridge space ends (really? How do you do bigger carts?) The signature gives the content of those last 16 bytes, but it's not important what that is since it isn't checked. I've added the resulting binary of my programming efforts as well. It's not very much yet, and far from a playable game, but it may be a hint of what I'm thinking of... Oh, and here's the main character of the game, but it isn't implemented yet... roadtest.bin

Well, in this case I think that my version was improved both speed- and size-wise since like Atari2600land's original version, it runs down in a straight line, only that it's much shorter and thus also should execute much faster. But I agree that there's often a trade-off between speed and size, for instance, you can probably draw objects the fastest if they're stored with a pixel per byte in the ROM, while compressing them saves space, but takes additional time for un-compressing. And sometimes you may also have to optimize for memory footprint, which is evident in the Channel F where there's effectively only 64 bytes of readable and writable RAM (in addition to the video RAM you can't read from). Thus you may be forced to compress the game data you store somewhat to get it all into memory, which slows down execution, or draw as much data as possible off pre-calculated tables in the ROM instead of generating it on the fly.

OK, now... seems like this thread got abandoned without finding a proper solution for the problem. I'll try to find one here, but let's go step by step so that you can follow me. First, let's see what this code actually does. I'll just pick the first sequence here.. but first, let's get some terminology straight... The ISAR is actually a pointer to one of the 64 registers in the register file. Its upper half (3 bits) gets loaded with LISU, and its lower half (3 bits) with LISL. So LISU 3, LISL 2 selects register 2 in bank 3, if we say we have 8 banks with 8 registers each. The ISAR retains its value until it gets overwritten, so if you access multiple registers in the same bank, you only have to update the lower half of the register by doing LISL, but not LISU. Then, LR S, A does not overwrite the ISAR (which would be the pointer), but the register which the ISAR currently points to, with the contents of A. Therefore, LI (6*16) + 2 does not set the ISAR, but only the A register. To write that value to the ISAR, you have to do LR IS, A. However, this takes more bytes than doing LISU and LISL. These two only take one byte each while you need 2 bytes for the LI (6*16) + 2 instruction and one more for LR IS; A. In Carlsson's first proposal, before this is done, the loop value is being added (minus a constant) in order to loop through the registers. But that's not what the original code does, instead it always works on the same three registers. So, with that out of the way, let's see what the code actually does... LISU 3 ;point the ISAR at bank 3 LISL 2 ;register 2 of bank 3 lr A, S ;load the value from that register into A LISU 3 ;point the ISAR at bank 3 (this is useless, it already points at bank 3!) LISL 6 ;register 6 of bank 3 lr S, A ;load the value from A into that register (which is useless because it's not accessed after that) inc ;increment A lr S, A ;and load the value from A into the same register again (without the first value having been used) LISU 3 ;point the ISAR at bank 3 (this is useless, it still points at bank 3!) LISL 4 ;register 4 of bank 3 XS S ;EXOR the value of A (which is also in Register 6 of bank 3) with the value of register 4 bank 3 bz subLives ;and branch to subLives if the value in A is now 0, that is, the EXORed values were the same Now maybe there's one more useless line up there, but only if the value of register 6 of bank 3 isn't being used after branching to subLives. In that case we don't need to write to that register at all because the changed value is in A anyway, and we don't need it after the comparison. Now, Carlsson's 2nd attempt has put this into a loop, but still retains the useless statements shown above. With those gone, Carlsson's code would look like this... LIS 8 ;start loop at 8 LR r0,A ;into r0 LISU 3 ;select bank 3 for whole loop loop: LISL 2 ;read value from register 2 in bank 3 lr A, S ;lr S, A obviously is useless in that case as well since the value is still there AS r0 ;add loop variable, then subtract 5 (?) AI 251 LISL 4 ;point to register 4 to compare to XS S ;eor BZ subLives ;and branch if equal DS r0 ;otherwise decrease the loop value and loop back if > 0 BNZ loop Now this is still not the optimum solution because while the code is shorter, it's sill being executed in a loop, so it actually takes longer to execute than the unrolled code. However, the actual purpose of the code seems to be to check if the contents of register 4 in bank 3 fall within a range of -4 to 3 plus the contents of register 2 of bank 3. This doesn't have to be compared in a loop, rather you only need two comparisons against an upper and a lower boundary, which again depends on one of the two registers So, similar to the code posted above, I'd do this as follows: LISU 3 ;point the ISAR at bank 3 LISL 2 ;register 2 of bank 3 LR A, S ;load the value from that register into A COM ;complement A (this means A = 255 - A) LISL 4 ;point to register 4 of bank 3 AS S ;add that register to A, so now A contains the value of (Register 2 - Register 6 of bank 3 - 1) CI 2 ;Set carry flag if A > 2 BNC subLives ;branch to subLives if carry was clear (Reg. 2 - Reg. 6 <= 3) CI 250 ;else compare against 250 (set carry flag if A > 250) BC subLives ;branch to subLives if carry was set (Reg. 2 - Reg. 6 > -5) Let's see how this one works... we'll do some examples. Example 1: Reg. 2 = 100, Reg. 4 = 96. In this case, the collision should just fire... 100 gets loaded from Reg. 2 and complemented to 155. We add 96 from Reg. 4 and get 155 + 96 = 251. CI 2 here sets the carry flag because 251 is greater than 2, so the BNC command doesn't get executed. CI 250 here sets the carry flag because 251 is greater than 250, so the BC command fires, and a collision is registered. Example 2: Reg. 2 = 100, Reg. 4 = 95. In this case, the collision should not fire... 100 gets loaded from Reg. 2 and complemented to 155. We add 95 from Reg. 4 and get 155 + 95 = 250. CI 2 here sets the carry flag because 250 is greater than 2, so the BNC command doesn't get executed. CI 250 here clears the carry flag because 250 is not greater than 250, so the BC command doesn't fire as well, and no collision is registered. Example 3: Reg. 2 = 100, Reg. 4 = 103. In this case, the collision should just fire... 100 gets loaded from Reg. 2 and complemented to 155. We add 103 from Reg. 4 and get 155 + 103 = 258 - 256 = 2. CI 2 here clears the carry flag because 2 is not greater than 2, so the BNC command gets executed and registers the collision. Example 4: Reg. 2 = 100, Reg. 4 = 104. In this case, the collision should not fire... 100 gets loaded from Reg. 2 and complemented to 155. We add 104 from Reg. 4 and get 155 + 104 = 259 - 256 = 3. CI 2 here sets the carry flag because 3 is greater than 2, so the BNC command doesn't fire as well. CI 250 here clears the carry flag because 3 is not greater than 250, so the BC command doesn't fire as well, and no collision is registered. I think this is a pretty effective solution which doesn't need any additional registers or loop variables except for A.

Here are my games for this past week (April 16th through 22th) on modern systems... Android: Crazy Taxi: City Rush - 78 min. in 6 sessions Arcade: Dolphin Star - 3 min. Non-Eligible: Stockstream - 4 min. Online: Jelly Mario - 11 min. This week I played a bigger assortment of games while waiting for the assets of my deceased mother to be sorted out by the judge. I visited the "Prater", the famous Viennese amusement park this week to see what's new, and it also has got some arcades, although not nearly as much as 20-30 years ago. There I played "Dolphin Star", and I actually wonder if I should feel guilty for playing this since it's a video game conbined with a kiddie ride. The ride moves in a constant rocking motion while the game is in progress and stops as the game is over (and it's clear it's made for kids, not adults, though there is no such thing posted). In the game you play a dolphin in a 3D environment trying to catch as many starfish and bonus items as possible, and the game closes with a boss battle. I also played a racing game whose name I forgot for a few minutes just to test what it's got in store since it also appeared to be moving, but there's only a bit of rumble on the steering wheel and a bit of shock on your seat. In "Crazy Taxi: City Rush", I managed to complete the last regular mission, but there are still the medal missions to be completed. I called Stockstream non-eligible because it has ceased to be a game... when I got in again this week, I couldn't see any voting options anymore, so all you can do is watch somebody doing his daytrading routine. Finally, Jelly Mario is a take on Super Mario Bros. where everything's quite elastic, and Mario actually moves forward by rotating rather than running and jumping.

Here are my games for this past week (April 16th through 22th) on classic games... Atari 2600: Shifty Lifty - 2 min. Intellivision: Auto Racing - 23 min. in 3 sessions This week I played a bigger assortment of games while waiting for the assets of my deceased mother to be sorted out by the judge. On the Intellivision, I continued to play Auto Racing in order to map it out. I think there are very few distinct metatiles in it, actually, which are overlaid by some additional chunks. Then I tried "Shifty Lifty" on the Atari 2600, a game where you progress through a set of floors while trying to avoid elevators going up and down quickly. I think I've seen that one before on the TI-99 where it was called "Spy's Demise", as it was called on other systems as well.

In 1995 I didn't play that much in general since I was very active in the Karaoke scene. I worked as a KJ in 2 different clubs during that year and also making my own Karaoke backing videos on VHS tapes. To that end, I took my VCR with me to one of the clubs and used the Game Gear with TV Tuner as a monitor to cue up the videos. In principle, the systems I played on back then were the C-64 and the Amiga 500... maybe the Game Gear and Game Boy to some extent, but my mother played the Game Boy much more than me (Dr. Mario was her favorite game). I also still visited the arcades from time to time, more than I do now. I can't remember any new games I got in 1995 either. In the arcade, though, one game I liked to play back then was Splash, but it eventually got removed from the arcade. I was also fascinated by the new 3D games coming out there... I think Ridge Racer made its debut back in 1995 in our arcades, which was the first texture-mapped racing game running at 60 fps I got to know. But I actually didn't play it that much either.

Did you set the directive "processor F8"? If you did that and it still doesn't work, how about posting your code so that we can inspect what's possibly wrong?

Here are my times for this past week (April 9th through 15th) on modern games... Android: Crazy Taxi: City Rush - 84 min. in 7 sessions In Crazy Taxi: City Rush, I've completed all missions except for the last one, and I still need some upgrades to be able to finish it, but that next motor upgrade isn't far away.

Here are my times for this past week (April 9th through 15th) on classic games... Intellivision: Auto Racing - 33 min. in 4 sessions Hover Force - 10 min. in 2 sessions This week I completed the map of Hover Force on the Intellivision. Actually I'd like to publish it somewhere, but I still have to find a site that would accept Intellivision maps. Same thing for Auto Racing, but there mapping is a bit more tricky because you have to drive everywhere you want to take a shot while in Hover Force, you just fly over everything.

Here are my times for this past week (April 2th through 8th) on modern systems: Android: Crazy Taxi: City Rush - 91 min. in 7 sessions Twitch: Stockstream - 108 min. in 2 sessions I continued to play "Crazy Taxi: City Rush" on Android. By now I'm through 5 of the 7 missions of the "Hills" level, so 2 missions left. Stockstream has reopened under new management. However, the gameplay has been vastly simplified. You're now only able to vote among several optinos of what to buy or sell, and the operator of the game often executes more trades than those that are actually there for the players to vote on.

Here are my times for this past week (April 2th through 8th)... Intellivision: Auto Racing - 25 min. Hover Force - 27 min. in 7 sessions My mother's funeral as well as the soul mass are now through, so I had a bit more time for gaming. Aside from continuing my map of "Hover Force", I also played "AUto Racing" and started to make a map there as well, particulariy because there doesn't seem to be a complete map of it on the Internet.

Here are my times for this past week (March 26th through April 1st) on modern games: Android: Crazy Taxi: City Rush - 100 min. in 7 sessions I continued to play Crazy Taxi: City Rush, in which I'm still making progress. I think I'm through 4 or 5 out of 7 missions in the "Hills" district now, but there are still some upgrades to do before my cab is powerful enough to make the last mission.

Here are my times for this past week (March 26th through April 1st) on classic games: Colecovision: Pole Position (WIP) - 2 min. Intellivision: Hover Force - 31 min. in 3 sessions This week I did play some classic games. First, after reading the MAME driver of Pole Position, but not quite understanding it, I tried a WIP of Pole Position on the Colecovision. The player car is rendered quite beautifully, but the road is drawn very crudely and never goes into a curve. You can steer left and right, but there's no actual progression in the game. Then I picked up Hover Force again for the sake of mapping it out. I'm now in my 3rd attempt on mapping it... the 1st attempt was stiched together from Youtube videos, while attempt 2 and 3 are stitched together from MAME screenshots, but in attempt 2 they didn't quite match up. By now I've found out how the tile map works in this game, and it's best to take the screenshots so that one tile is fully visible with parts of the ones surrounding it.