Willsy Posted December 3, 2015 Share Posted December 3, 2015 @Tursi, You're correct of course, however, in TF, the cartridge has two entries on the cart menu - one for 40 column mode and one for 80 column mode. Each bank would still have two identical cart headers, but with only one entry (the 40 column entry) defined in each bank, rather than two. Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 3, 2015 Share Posted December 3, 2015 Ah ha!! Good point. Technically a game cart would probably have the game title. It would be kind of cool to have a little "Powered by TurboForth" icon or string in such titles. (My opinion only, of course!) 1 Quote Link to comment Share on other sites More sharing options...
am1933 Posted December 3, 2015 Share Posted December 3, 2015 Here's a snapshot of the game with the faster monsters. I must admit that this looks better even though now my score is abysmally low, so I'm making it official as version 0.85. I also hunted down and squashed the intermittent 2 player bug and made a couple of minor enhancements to the code along the way. https://youtu.be/gUqSojbV2aY Ahhhhh Haaaaa, that's the Jetpac I'm talking about, Compared to the ZX Spectrum, VIC 20 and BBC Micro version-this one is the best, it narrowly beats the Spectrum version due to the lack of attribute clash, all we need now is some sound-and let's face it, it won't take much to beat the Spectrum on the sound front Congratulations once again on a great coversion. P.S, what's next? ? 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 4, 2015 Author Share Posted December 4, 2015 Thanks! I'm glad it turned out well otherwise Willsy would have hunted me down and beat me with a club 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 4, 2015 Author Share Posted December 4, 2015 Ah ha!! Good point. Technically a game cart would probably have the game title. It would be kind of cool to have a little "Powered by TurboForth" icon or string in such titles. (My opinion only, of course!) Noted 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 4, 2015 Share Posted December 4, 2015 Noted I've already produced a stripped-down TF cart image (just 16K at the moment) that has a single Jetpac entry on the cart selection screen. It boots straight into TF. The auto boot code has been removed. It will simply execute a single word in the dictionay (i.e. JETPAC) upon startup and the game will start. I'll probably finish it this weekend. If the game had some sort of secret keypress on the game selection screen to drop out of the game you'd land in the full TF environment and would be able to write Forth programs! Too cool :-) 4 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 4, 2015 Author Share Posted December 4, 2015 That is just great! Now I need Omega to come up with a cool cart label One thing I should mention is that the bitmap splash screen, essentially the original Jet Pac one with just credits modifications, will need to load from disk for the disk-based Jet Pac since I don't have 12K of available RAM for it. That said, I wonder if there is a way compress the color and PDT image files into something like 8K so they can fit in low memory... I'll do some research on this. 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 4, 2015 Share Posted December 4, 2015 That is just great! Now I need Omega to come up with a cool cart label One thing I should mention is that the bitmap splash screen, essentially the original Jet Pac one with just credits modifications, will need to load from disk for the disk-based Jet Pac since I don't have 12K of available RAM for it. That said, I wonder if there is a way compress the color and PDT image files into something like 8K so they can fit in low memory... I'll do some research on this. Tursi's Convert9918 can RLE compress the splash screen to just under 6K. The attached XB program, generated from Convert9918, is a bit longer because it also includes the XB to display the image. jetpacxb.bas 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 4, 2015 Share Posted December 4, 2015 The unpack code is included in a subfolder of the Convert9918 archive, it is really straight forward and should port easily, let me know if you have any trouble. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 4, 2015 Author Share Posted December 4, 2015 Excellent! I'll take a look at it. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 5, 2015 Share Posted December 5, 2015 RLE - no header is attached. The files are RLE encoded as such: Count Byte: - if high bit is set, remaining 7 bits indicate to copy the next byte that many times - if high bit is clear, remaining 7 bits indicate how many data bytes (non-repeated) follow Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 5, 2015 Author Share Posted December 5, 2015 Looks very straightforward to implement the decompression. Thanks What kind of image loss an we expect with RLE? I presume it would be not be much of an issue for the TI's low bitmap resolution. Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 5, 2015 Share Posted December 5, 2015 RLE is lossless. Looking at the Jetpac image you'll get a reasonable level of compression on the bitmap image, but the colour table will compress very nicely. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 9, 2015 Author Share Posted December 9, 2015 Jet Pac cart and disk label, courtesy of Omega 3 Quote Link to comment Share on other sites More sharing options...
Iwantgames:) Posted December 9, 2015 Share Posted December 9, 2015 Nice Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 9, 2015 Share Posted December 9, 2015 Wow that's awesome! TURBOFORTH is one word, not two 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted December 9, 2015 Share Posted December 9, 2015 (edited) Kerrrrrrrrrrrr AP! I'll fix it this evening when I get time,... thanks. Edited December 9, 2015 by --- Ω --- 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted December 9, 2015 Share Posted December 9, 2015 Okay, here is the high-resolution (revised) JetPac label. I uploaded it in a .ZIP because Atari Age has a habit of degrading images and even re-sizes them down, which can really make them 'kinda sucky' if you plan to print them. JetPac - Label.zip 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 10, 2015 Author Share Posted December 10, 2015 RLE - no header is attached. The files are RLE encoded as such: Count Byte: - if high bit is set, remaining 7 bits indicate to copy the next byte that many times - if high bit is clear, remaining 7 bits indicate how many data bytes (non-repeated) follow Rasmus, in looking up RLE compression, there seem to be several variants of it. The original RLE simply had 2 byte packets, the first one indicating the number of repetitions and the second the byte to be repeated. This is a bit different from what you indicated. I'm having problems extracting a usable image from the compressed files, and I want to make sure I am using the right decompression scheme... Quote Link to comment Share on other sites More sharing options...
Iwantgames:) Posted December 10, 2015 Share Posted December 10, 2015 Loving that label Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 10, 2015 Share Posted December 10, 2015 Rasmus, in looking up RLE compression, there seem to be several variants of it. The original RLE simply had 2 byte packets, the first one indicating the number of repetitions and the second the byte to be repeated. This is a bit different from what you indicated. I'm having problems extracting a usable image from the compressed files, and I want to make sure I am using the right decompression scheme... RLE is just a term, not a file format. It applies to anything that compresses by encoding a series of bytes, thus "run length encoding". Rasmus posted the system I'm using from the Convert9918 documentation. I sent the unpack C source code last night, that's proven working. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted December 10, 2015 Author Share Posted December 10, 2015 OK got it. Thanks Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted December 10, 2015 Share Posted December 10, 2015 RLE is just a term, not a file format. It applies to anything that compresses by encoding a series of bytes, thus "run length encoding". Rasmus posted the system I'm using from the Convert9918 documentation. I sent the unpack C source code last night, that's proven working. I am also interested in the details of your RLE method. Is the 7-bit count value the actual count - 1, i.e., does 0 – 127 map to actual counts of 1 – 128? ...lee Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 10, 2015 Share Posted December 10, 2015 I am also interested in the details of your RLE method. Is the 7-bit count value the actual count - 1, i.e., does 0 – 127 map to actual counts of 1 – 128? No, it's not even that smart, it's the actual count: void RLEUnpack(unsigned int p, unsigned char *buf, unsigned int nMax) { int cnt; unsigned char z; VDP_SET_ADDRESS_WRITE(p); cnt=nMax; while (cnt > 0) { z=*buf; if (z&0x80) { // run of bytes buf++; z&=0x7f; raw_vdpmemset(*buf, z); buf++; } else { // sequence of data buf++; raw_vdpmemcpy(buf, z); buf+=z; } cnt-=z; } } void ldpic() { // loads a picture - we aren't actually loading from disk // we are un-RLE-ing the image from ROM RLEUnpack(0x0000, TITLEP, 6144); RLEUnpack(0x2000, TITLEC, 6144); } 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted December 10, 2015 Share Posted December 10, 2015 Here's the assembler code I used in Sabre Wulf: ******************************************************************************** * * RLE decode to VDP RAM * * The files are RLE encoded as such: * Count Byte: * - if high bit is set, remaining 7 bits indicate to copy * the next byte that many times * - if high bit is clear, remaining 7 bits indicate how * many data bytes (non-repeated) follow * * R0: Destination VDP RAM address * R1: Source CPU RAM address * R2: Number of target bytes to decode * RLEDEC MOV R11,*R10+ * Push return address onto the stack BL @VWAD * Set up write address RLEDE1 MOVB *R1+,R3 JLT RLEDE3 * Copy next n bytes ANDI R3,>7F00 SWPB R3 S R3,R2 RLEDE2 MOVB *R1+,@VDPWD DEC R3 JNE RLEDE2 JMP RLEDE5 * Copy next byte n times RLEDE3 ANDI R3,>7F00 SWPB R3 S R3,R2 MOVB *R1+,R0 RLEDE4 MOVB R0,@VDPWD DEC R3 JNE RLEDE4 RLEDE5 MOV R2,R2 JGT RLEDE1 * Return DECT R10 * Pop return address off the stack MOV *R10,R11 B *R11 *// RLEDEC 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.