Asmusr

In this demo project I wanted to try out two new things on the same kind of space graphics I use in the half-bitmap mode project (which, BTW, is still going strong): Horizontal scrolling Scrolling in normal graphics mode 1 http://www.youtube.com/watch?v=Js4hhBIdJlc The attractive thing about using mode 1 for scrolling is that it's possible to use pattern table switching, which is not possible in bitmap mode. This demo uses four pattern table buffers, each divided into a low character set (0-127) and a high character set (128-255). This allows you to pre-load up to 128 patterns in 8 scroll positions/frames into VDP RAM. The demo also utilizes two name/screen table buffers - one for the low character set and one for the high character set. The scheme for switching buffers goes like this: Frame 0: Pattern table 0, Name table 0 - low Frame 1: Pattern table 1, Name table 0 - low Frame 2: Pattern table 2, Name table 0 - low Frame 3: Pattern table 3, Name table 0 - low Frame 4: Pattern table 0, Name table 1 - high Frame 5: Pattern table 1, Name table 1 - high Frame 6: Pattern table 2, Name table 1 - high Frame 7: Pattern table 3, Name table 1 - high In terms of performance only the preparation of the name tables matters. Since we have 4 frames to prepare a table of 768 bytes we need to send only 192 bytes to the VDP RAM per frame. This leaves plenty of CPU cycles for sprites and other stuff - even at 60 FPS. The demo shows different speeds from 15 FPS to 60 FPS at 1 pixel/frame, and the top speed is 60 FPS at 2 pixels/frame. When moving 2 pixels you only have 2 frames to prepare a name table, i.e. 348 bytes per frame. Another good thing about mode 1 compared to half bitmap mode is that all 32 sprites can be used without running into the 'duplication bug'. The downside of using mode 1 is the limited colors, of course. Two adjacent tiles in the direction of scrolling must either use the same foreground color or the pattern for one of them must not contain any foreground color pixels (i.e. a 'space'). The same rule applies to the background colors. (Actually, horizontal scrolling in bitmap mode is subject to the same color limitations but applied to each individual scan line.) I'm going to post an update to the Magellan thread that provides better tools for designing mode 1 scrolling graphics plus an export function for generating the transition map, which I used for this project. This attachment contains a dsk file with the demo (looks much better in Classic99 and even better on hardware than on the video). hscroll.zip The source code is also included. Note that the code is overly complicated because of the scrolling at different speeds and because of the wrap around of the map. If these features were not required it could be done much simpler.

FYI, I found these chipsets on ebay for building your own TI-99/4A or Geneve computer: eBay Auction -- Item Number: 121131711904 eBay Auction -- Item Number: 121131711904 It looks interesting, but far too advanced for me.

There's a Hunt the Wumpus remake here: http://www.dreamcodex.com/

Great, thank you. It was the quotes. I had to edit a registry entry under HKEY_CLASSES_ROOT\dsk_auto_file\shell\open\command to make it work.

Perfection? Well, I also loved this game as a child, and I might be walking into a mine field here, but technically, since the color of the scrolled area is all yellow they should not have used bitmap mode. They could have done this much more efficiently using normal graphics mode, and the scrolling could have been pixel smooth and full screen.

Thank you Tursi, this is great. Now I can see how the scrolling in Parsec was done, for instance, and I can use it for debugging my own code. I also have a wish for Classic99: an easy way to catalog a disk from windows, like in Win994a.

I still don't see many of the images after having cleared the cache multiple time. Using Chrome version 27.0.1453.116 m. E.g. if you open this link http://tigameshelf.net/Images/AGRESS2.gif you just get an empty tab.

I'm also looking for a cable, but it's not easy to find. Just finding a 44 pin card edge connector is difficult. Perhaps that's why the connector on my nanoPEB looks like it was cut from a larger connector and then the cut edge was melted? Perhaps you need to make your own adapters for a standard ATA/IDE cable?

What is this for, if you need a hardware-programmer to change anything?

Just an update to show that my space scrolling demo is still (slowly) progressing. There have been some tough pills to swallow in the process of turning the demo into a framework for a game, but it still looks like a doable project. http://www.youtube.com/watch?v=yclHTPRWZko The frame rate has dropped from 60 to 30 FPS to provide time for a game loop, but to compensate you can now scroll either 1,2 or 4 pixels per frame. At 2 pixels per frame it still looks nice and smooth, but at 4 pixels per frame it becomes quite bumpy. Because of the >8 sprite bug in half bitmap mode I now update all 3 VDP pattern tables unless an F18A is detected (Classic99 detects an F18A by the method I use). This makes the frame rate drop further to 20 FPS, which is not terrible (see how it looks in Win994a), but my plan is to dynamically switch full pattern table updating on/off depending on whether more than 8 sprites are visible. Has this been tried before? (Note: at the moment I don't think >8 sprites are ever visible). I have added a basic example of interaction with the scrolling background - you can now shoot the pyramids. This requires more character patterns to be updated so it has to be limited to a few tiles. I have also added basic support for enemy ships moving around in predefined paths (no interaction yet), and a few animations. Disk image (E/A 3: SCO) and source code attached. spacescroll2.zip

I won't claim I understand all the technical details, but it sounds absolutely amazing. I can't wait to get one... Is it also intended for distributing specific games and software, or would developers rather release their software as a file that people can upload to their carts?

Thanks. Does the adapter look like it's home made?

That's sounds very exciting, but will it require a PEB? What are the specifications?

Thank you, Matthew, for the information. Actually our local electronics store has some 74LS379 chips left that I might buy for future use, but I think I will stick to the 4 bank supercart as my project because of the cost of getting a circuit board for the 64K cartridge. It's good to know that you don't have to add the GROM so I can wait with this until I find another E/A card. I'm not sure what the difference is between a supercart, a multicart and a megacart? This is my shopping list for a 4 bank supercart from www.Jameco.com (enough for two carts):

I'm not usually a hardware guy, but I think it would be really interesting to make my own 4 Bank 8K Supercart <http://www.mainbyte....art_4bank.html>, and I believe I have found all the components on <https://www.jameco.com/>. The thing that's holding me back is that I have to remove the GROM from my precious (gollum, gollum) E/A card. Does anyone know what would happen if you don't add the GROM, could you still use the RAM for storing programs? An alternative to soldering the GROM onto the board would be to place it in an IC socket - slightly less risky I guess. I've also thought about building a MegaMod 2010 cart <http://home.vodafone...l#megamod_2010> because I use Cf2k and CfHdxS a lot, but it looks like it would cost $150 to have 2 of Jon Guidry's circuit boards manufactured by <http://www.expresspcb.com/>, and then I would also need get the EPROM: perhaps order it from <http://www.mainbyte....re/EPROMS.html>, or invest in my own EPROM burner. Does anyone have recent experience with any of these cart projects? Someone from the EU perhaps, who knows a cheaper way to order these components, or suggestions for other great cart building projects? Thanks in advance for any advice you can provide.

I'm interested in the cable. The nanoPEB does not have a cable like that. I have read somewhere that it's a standard IDE/ATA cable, and a have one of those, but the terminators are not circuit board edge connectors but ATA connectors with a lot of holes. Which adapters do you need to put your nanoPEB in a box? Thanks, Rasmus

No you're right, of course, the CF7+ has a parallel port, but you can still make a cable. It just requires some more work and the addition of a wire to the CF7+: http://home.vodafone...w_ti99hdx_cf7 .html After I made a cable for my nanoPEB I have hardly ever removed the memory card. Don't get me wrong, I think a wireless connection would be great.

Guess you would also need a CF to SD adapter? Have you tried a serial cable with the CF7+ instead of moving the card?

Come on, you know you need it!

Perhaps something for you? http://www.dba.dk/texas-ti-99-4a-komplet-med/id-91548477/ http://www.stargames.be/shop/105-accessoires

I attached my European console to my Sony Bravia KDL-40EX653 television using a simple component cable from Retro Computer Shack on ebay, and look what I got: an almost perfect picture with square pixels and none of the color bleeding I get when I use the RF modulator. From what I have been reading I'm not sure if anyone else have found a TV that works as well as this. Perhaps Sony is the way to go?

Sorry for breaking into this thread, but I have a question about bit shifting. When you want to shift a fixed number of positions you can do it like this: SRA R1,3 When you want to shift a variable number of positions you load the number into R0 like this: MOV @MYVAR,R0 SRA R1,0 But when R0 is zero the shift is not zero positions but 16, according to the E/A manual. This means you have to add a check: MOV @MYVAR,R0 JEQ SKIP SRA R1,0 SKIP This makes the code longer and more difficult to understand. Is there a trick to avoid this? I don't understand why the instruction was designed like this. When do you need to shift 16 positions? Why not just shift zero positions?

I can confirm that in Tursi's test program the bug does not appear when you have 3 pattern tables and only one color table. I tested it on a European (TMS9929A based) console. Moving the sprite pattern table to >3800 did not change anything.

Thanks Tursi.

Probably mostly known in Europe, but I would have included the Amstrad CPC 464 in the table (a.k.a. Schneider in Germany and the Arnold in France). This was the computer I went for after the TI, in 1984. It was Z80 based with 64K RAM, and it came with a color monitor as standard and a built-in tape drive. It had three bitmap modes (640x200 - 2 colors, 320x200 - 4 colors, and 160x200 - 16 colors (out of 27)). It had a great Basic in ROM and easy access to machine code. The sound was also pretty good, but could not compete with the C64. I think its biggest problem was the lack of sprites and scroll registers, and the decision to use non-standard 3" floppy disks.