retroclouds

Yes, that would be double buffering. As mentioned, I suppose you are using graphics 1 mode. For displaying a screen in that mode you need 768 bytes [32*24] for the tiles and 2048 bytes [256 * 8] for the patterns that make up the tiles. This means you need a total of 2816 bytes for displaying a screen (not including the color table). Knowing that the VDP has 16K of video ram this leaves plenty of space to "store" multiple screens in the VDP memory. By setting the VDP write-only registers #2 and #4 to the correct values, it will immediately display the new screen. From the VDP programmers' guide .... VDP register 2 ============== Register 2 tells the VDP where the starting address of the Name Table is located in VRAM. The range of its contents is from O-F. The contents of the register form the upper four bits of the 14-bit VDP address, therefore making the location of the Name Table in VRAM equal to (Register 2) * 400 (Hex). VDP register 4 ============== Register 4 tells the VDP where the starting address of the Pattern Table is located in VRAM. The range of its contents is from 0-7. The contents of the register form the upper three bits of the 14 bit VDP address, therefore making the location of the Pattern Table in VRAM equal to (Register 4) * 800 (Hex). Note, perhaps you should create a new development post for your project here on atariage. I'm sure quite some folks will be interested in it

Very nice! Also very interesting. I'm not a colecovision programmer, more of a TI-99'er (which has the same VDP). Do you mind sharing how the writes to the VDP are done ? Could imagine there are a few ways for speeding things up, which most likely you already know. Here is some of the stuff I used to do for the TI when dealing with the VDP. Should in some extent also work for the colecovision I guess: * Use assembly language for speed critical tasks * Use inline code instead of subroutine calls where possible * Avoid many small individual writes, instead use big block writes where possible * Guess the game screen is in graphics1 mode, so you should be able to have multiple pattern and screen image tables in the 16K VDP ram. 1. Fill inactive pattern/screen image table while the VDP registers point to the active pattern/screen image table 2. Switch VDP registers to now point to the filled tables, updating the screen display 3. And back to 1 Anyway, looking forward seeing more of your project

Thanks for asking Owen. I've barely done any TI stuff lately, so no progress. Crazy life got in the way again. Just yesterday I got back home from a trip to Belgium. Went to see my relatives, so I was rather quiet in the forums too The good thing is that I have a 3 week vacation coming up right now. Ask me again at the end of August, I should have something to show you

Thanks for posting, Tim. Yes, you are absolutely right, and just such a thing is certainly the FIRST thing I would do. Here's the only thing though... how many of us have hardware and emulators? A hundred? Two hundred? Of those two hundred, how many are interested in playing video games? Of those interested in video games, how many RPG gamers are there out there? A person willing to play a game for 10-20 hours to beat it.... We're essentially limited in most part to THIS FORUM!!! We're the ones who love games, love programming, and love supporting others to do the same. Over on the list, 90% of those people have never played any of the SSGC games, they don't care about new software, and for the most part--- they are mostly great people who enjoy talking about the TI as something they remember fondly. I love them all, they're all great people. But really... show of hands... Who thinks fdos, epergrem, jacques, tom, or any number of others would really enjoy a CRPG? It's really quite simple if you follow me. The ones in THIS Atariage community who love games are simply co-designers, as far as I"m concerned. I look at this thread like a development document, in a way, with hundreds and hundreds of co-authors. You guys are my inspiration, my BETA testers, my co-conspirators, mentors, all wrapped up into one little community. So, here's the rub. YOU are all co-authors of the game.... you are all on the BETA testing team... so who are we doing this all for? Honestly, I'm hoping we can find a way to go the way of the "wrap" as was suggested previously. That way, this game can be a testament to the /4a. An accessible, understandable, labor of love showcasing the TI and what it can do. "Here, RPG world... you have a new CRPG to play, it's Windows executable, it's well done, it's 100% documented, 100% tested and guaranteed to play well. And best part... It's written on the TI-99/4a home computer.... 16k of RAM, 256 bytes of scratchpad RAM... and we did it in spite of all the limitations and challenges! Come to the /4a-side. See what's possible?" That's what excites me about the project... There is such a HARDCORE community of RPG lovers and enthusiasts who have ALL heard of Tunnels of Doom. Tens of thousands of people who are looking for a project like Adamantyr's "Realms of Antiquity" or my own RPG (to a lesser extent). Let them eat cake. =) I wouldn't mind seeing Beryl as an executable windows file. It would open your game for a further audience. Sometimes, it's these little things that matter. Also "wrapping" the emulator and game as a single executable is not that uncommon in other retro game scenes

Just wondering, could there be a way for TI assembly language software to detect if this controller is attached ?

hmmm thinking about it, I could see A="fire" and B="magic lamp" in Tutankham

Holy cow! That is fantastic! I for one, want to see this happen and I'd love to support it in future games

I really like your utility, it's very cool to try some different fonts :thumbsup: ... and ofcourse it's great to run it in the browser

Hi Rich, sure send them along. Looking forward to it

I would first try it with either classic99 or MESS. Checkout the emulator section in our development resources thread.

Very nice! I like them, I'll sure be using these in my next update. :thumbsup:

I've heard of this solution years ago, and it's probably filled with patches I didn't want to include in my own web site... a javascript solution already 24KB will simply double the size of my web site just to support IE6... I don't feel it's justified. But, back to the main subject, anybody tried this version of my devkit yet? It works with all my musics you can find here and there on Atariage. jQuery is really cool. I have been using it for some of my projects at work. 24K is not that bad I'd say. A lot of the images on the web are way bigger than that, and then you have the browser cache. Either way, great job on your website Daniel!

I'd love to see Galaxians for the TI. Colecovision has it, should be doable for the TI as well.

oh yes Tursi, a manual would be great. Also have an idea for the debugger (perhaps I already mentioned a while back): Would it be possible to toggle the breakpoints on/off using checkboxes (in the breakpoints list) ? Being able to save/load your breakpoints would also be real cool

Thanks. Yes, you just add the 2nd file to the end of the first. If you are on windows you can do that by typing: copy /B baby_bank0.bin+baby_bank1.bin baby.bin

ok, here's a VDP dump where the background colors are not correctly imported: Name table >0800 Color table >0780 Pattern table >1000 You'll have to switch the background to "black". VRAM.zip After importing you'll see that the walls on the screen are missing. To make them visible, you have to set the background color of L1 to yellow and L2 to white. Thinking about it, perhaps the pulldown for the screen background color could be added to the import dialog as well

I didn't have time to test it out on other emulators (MESS) nor did I try it on the real deal yet. You should be able to run this image when using a GRAM kracker device. Also if both ROM images are concatened as a single binary image and burned on a 16K EPROM it should work with the newer boards from Jon (keeping my fingers crossed)

This thread describes my progress on turning Bouncing Babies into a cartridge ROM image. Warning: Only runs with 32K memory expansion RAM. This ZIP file contains the ROM image and source code baby_cart_conversion.zip Windows tools used for doing the conversion * classic99 (and its great debugger) * HxD hex editor * winasm99 (cross-assembler from Cory Bur included with the win994a emulator) * PERL The following reference material was used for doing the conversion * Graphics Programming Language (GPL manual, see Development Resources thread) * TMS9900 Assembler auf dem TI-99/4A (great assembler manual written in german) Others * Spectra2 alpha, my own assembler library for writing games Here we go: 1. I copied the #EA5 files (BABY5 and BABY6) in my classic99 DSK1 directory and started classic99. 2. Started the Editor/Assembler cartridge in classic99 and also opened the classic99 debugger window. 3. Selected #EA5 (RUN PROGRAM FILE) and entered DSK1.BABY5 4. The game started and while it was running I inspected high memory from >A000->FFFF Noticed that the first instruction starts at >CFDE. 5. Reset emulator and set breakpoint at >CFDE, then repeated step 3 6. The debugger halts execution at >CFDE, that's before the game does something. I press the "Dump RAM" button in the emulator and confirm the dialog requesting if I do want a dump. 7. A 64 kilobyte file MEMDUMP.bin is written in the classic99 directory, that's the one I'm looking for. 8. Started HxD hex editor and opened MEMDUMP.bin, I looked for the memory range >CFDE->FFFF. 9. I split this memory range and dumped it from HxD in the binary files "baby_0000_to_17FF.bin" and "baby_1800_to_3021.bin" They are pretty much a dump of the game split in two files. 10. Time to do some perl now, I recalled I had a short PERL script I used for turning bytes into assembly language data statements. With the PERL script I created "baby_0000_to_17FF.a99" and "baby_1800_to_3021.a99" 11. It's obvious that the game won't fit in a 8K ROM image, we'll need 2 banks so we'll be switching banks. Time to start notepad++ and do some hacking. I don't want to start from scratch so I used SPECTRA2 for doing things like memory setup, setting VDP registers, doing the bank switching, etc. 12. For each bank I create a new project in winasm99, called "baby_bank0.apf" and "baby_bank1.apf" 13. Ready to roll, assemble both projects and important, select option for creating binary files "baby_bank0.bin" and "baby_bank1.bin" 14. Ready to run our newly created bank-switched ROM image, reset classic99 after adding the below to your classic99.ini [usercart2] name=Bouncing Babies rom0=C|6000|2000|D:\projekte\baby_cart_conversion\baby_bank0.bin rom1=X|6000|2000|D:\projekte\baby_cart_conversion\baby_bank1.bin Here's the extract for the code in bank0 *************************************************************** * Cartridge header ********@*****@*********************@************************** AORG >6000 GRMHDR BYTE >AA,1,1,0,0,0 DATA PROG BYTE 0,0,0,0,0,0,0,0 PROG DATA 0 DATA KERNEL BYTE 15 TEXT 'BOUNCING BABIES' *////////////////////////////////////////////////////////////// * KERNEL MEMORY SETUP *////////////////////////////////////////////////////////////// * KERNEL ..: *************************************************************** * KERNEL - Spectra2 Kernel memory setup *************************************************************** * B @KERNEL ********@*****@*********************@************************** KERNEL LIMI 0 ; Turn off interrupts LWPI WS1 ; Activate workspace 1 LI TMP0,VM1 ; Graphics mode 1 BL @LOADVR ; Load shadow registers LI STACK,BASE1 ; Set data stack to base MOV @JPCODE,@SWBANK ; Bank switching trampoline code MOV @JPCODE+2,@SWBANK+2 ; Bank switching trampoline code B @MAIN ********@*****@*********************@************************** * VDP graphics mode 1 - See table definitions VM1 BYTE >00,>E0,>00,>0E,>01,>06,>00,>F3,32,>00 ; Graphic mode 1 JPCODE DATA >04D4,>0455 ; CLR *R4 and B *R5 * :.. MAIN BL @PUTVR ; Put shadow registers BL @FILMEM ; Clear memory A000-FFFF DATA >A000,>00,>FFFF->A000 BL @CPYM DATA BABY0,>CFDE,>17FF ; Copy part 1 to HIMEM >CFDE LI TMP0,BANK1 LI TMP1,>6070 ; Jump to copy code in bank 1 B @SWBANK .... BABY0 COPY "D:\Projekte\baby_cart_conversion\baby_0000_to_17FF.a99" END And this is the code for the second bank: *************************************************************** * Cartridge header ********@*****@*********************@************************** AORG >6000 GRMHDR BYTE >AA,1,1,0,0,0 DATA PROG BYTE 0,0,0,0,0,0,0,0 PROG DATA 0 DATA KERNEL BYTE 15 TEXT 'BOUNCING BABIES' *////////////////////////////////////////////////////////////// * KERNEL MEMORY SETUP *////////////////////////////////////////////////////////////// * KERNEL ..: *************************************************************** * KERNEL - Spectra2 Kernel memory setup *************************************************************** * B @KERNEL ********@*****@*********************@************************** KERNEL LIMI 0 ; Turn off interrupts LWPI WS1 ; Activate workspace 1 LI STACK,BASE1 ; Set data stack to base MOV @JPCODE,@SWBANK ; Bank switching trampoline code MOV @JPCODE+2,@SWBANK+2 ; Bank switching trampoline code B @MAIN ********@*****@*********************@************************** JPCODE DATA >04D4,>0455 ; CLR *R4 and B *R5 GPLWS BYTE >13,>F5,>09,>F0,>00,>A0,>43,>81 BYTE >CF,>DE,>02,>70,>06,>64,>4F,>F3 BYTE >00,>00,>00,>1E,>38,>00,>06,>1C BYTE >00,>00,>98,>00,>01,>08,>8C,>02 ********@*****@*********************@************************** MAIN LI TMP0,BANK0 LI TMP1,>6024 ; Start of code B @SWBANK BL @CPYM DATA BABY1,>E7DE,>17FF ; Copy part 2 to HIMEM >E7DE BL @CPYM DATA GPLWS,>83E0,30 ; Setup GPL Workspace as in Editor Assembler MOV @GPLWS+30,@>83FE ; 32 would have overwritten return stack B @>CFDE ; Start game in HIMEM ... BABY1 COPY "D:\Projekte\baby_cart_conversion\baby_1800_to_3021.a99" END I didn't include the SPECTRA code in the above snippets as it might distract from what we are trying to explain here Basically you don't know which bank will be selected when the TI-99/4A is powered up, that is the reason both banks include a cartridge header. If the second bank is selected first, all it does is a bank-switch to the first bank. This is what happens: BANK 1 ===== 1. If we start in BANK1 by coincidence, then all we do is setup workspace & stack and copy bank-switch trampoline code into scratch-pad memory. 2. We use the trampoline code in scratch-pad memory to select BANK0 and jump to the KERNEL subroutine there. BANK 0 ===== 1. This kernel actually only does a basic scratch-pad memory setup (workspace, bank-switch trampoline code, etc.) and sets VDP shadow registers the same way as in Editor/Assembler, when done it jumps to MAIN 2. In MAIN, we set the hardware VDP registers based on the values in the VDP shadow registers 3. Clear high memory >A000 to >FFF by filling it with >00 4. Copy >17FF bytes from game code in BANK0 to high memory >CFDE 5. We use the trampoline code in scratch-pad memory to select BANK1 and jump to >6070 (MAIN) BANK 1 ===== 1. We copy the remaining >17FF bytes from game code in BANK1 to high memory >E7DE 2. Almost done now, we only need to set the GPL workspace in scratch-pad memory the same was as if we would be using the Editor/Assembler module. So copy 32 bytes to >83E0 3. Ready to go, jump to start of game in high memory: B @>CFDE Below is the PERL script I used for turning the raw bytes into assembly data statements. It's nothing fancy just a quick hack. #!/usr/bin/perl use Data::Dumper; our @rom = (); our $size = 0; readdump('baby_1800_to_3021.bin'); #datadump('780','800'); datadump('0','17FF'); exit; sub readdump { my $fname = shift; if (-e "$fname") { my $image = ""; open(ROMH, "$fname") or die("Could not open \"$fname\"\n"); binmode ROMH; $size = read(ROMH, $image, 16384); @rom = unpack("C*", $image); close(ROMH); } else { die("no ROM!"); } } sub datadump { my $start = hex shift; my $end = hex shift; my $nl = 0; my $cm = ''; for (my $l=$start; $l<=$end; $l+=2) { if ($nl == 0) { print " DATA "; $cm = sprintf(" ; >%X - >%X\n", $l, $l+7); } printf("%s>%02X%02X",$nl > 0 ? ',' : '',$rom[$l],$rom[$l+1]); if ($nl == 3) { printf($cm); $nl = 0; } else { $nl++; } } }

Just tried it, works like a charm. According to the file size its roundabout 14K. So it shouldn't be too hard to make a ROM image of two 8K banks containing your game and some wrapper code for copying to high memory. I'll give it a spin and let you know (might take a few days though, limited TI time this week) I just tested the #EA5 version on the TI-99/4A: it works great. Have to say that I'm impressed with the quality of your game. Also didn't think that there are basic compilers around that work that well. Very slick.

nice Dunno if the button style is appropriate for indicating a particular status. Would be cool though for things you can access, e.g. key for accessing authors' home page, etc. I wouldn't mind using some TI game characters either. After all, we're in the TI-99/4A game programming forum, I like the idea of using munchan and tombstone city. It wouldn't be a problem adding a legend and we also have the URL title that appears when hovering over the icon. Thanks for your help, appreciate it a lot.

cool I'm happy with anything between 16x16 and 32x32 Bigger would be too big I guess

Just bumping this thread, anyone willing to create a few artwork icons for the dev thread? please Believe me, you just don't want to see the artwork I come up with

Just tried it, works like a charm. According to the file size its roundabout 14K. So it shouldn't be too hard to make a ROM image of two 8K banks containing your game and some wrapper code for copying to high memory. I'll give it a spin and let you know (might take a few days though, limited TI time this week)

This is what the classic99 debugger shows when trying to load via #EA5. I'd really love to try the #EA5 version. Is there a baby6 file missing ?

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right? Have you every downloaded a XB autoload file from TIGAMESHELF.NET and transfered it? I wonder if that is the problem. If you have EA here is the EA5 file for it. When I tried to load BABY5 using #EA5, I get an error "07". It seems it's also trying to load BABY6 ?