Jump to content

Recommended Posts

This is my preliminary proof of concept that it's possible to do raster effects on the TI-99/4A. I have tested it in MESS and on a F18A console.

 

Could someone please try it on a console with the original VDP?

 

 

The original image looks like this:

 

post-35226-0-67804300-1461968325_thumb.png

 

The demo is changing the color table every 16 scanlines to generate the checkerboard effect, and after each frame it is changing the starting point to make the image move..

 

SPLITSCRN.dsk

splitscreen2.a99

  • Like 4

Vary output colour = change colour sets mid screen, so you get bigger colour resolution? Then I understand, but bigger resolution is different from a bigger palette. Or perhaps you can multiplex colours on MSX so they appear like a third one.

 

Yeah, as Asmusr points out, the later has been done on MSX. I had never seen it done on TI, though after some reading and thinking it seems that this can be done on TI as well? Cool B)

 

This is my preliminary proof of concept that it's possible to do raster effects on the TI-99/4A. I have tested it in MESS and on a F18A console.

 

Could someone please try it on a console with the original VDP?

 

Quite excited to see the results of this! Also, does anyone know how the name table should be laid out for Tursi's convert9918 program using the Bitmap 9918A format? I'm doing a regular 00, 01, ..., FF, 00, 01, ..., FF, 00, 01, ..., FF but I'm getting some patterns swapped around :(

 

Edit: 00, 01, ..., FF, 00, 01, ..., FF, 00, 01, ..., FF is right. I just had a bug in my code!

Edited by orbitaldecay
  • Like 1

Seems to work as advertised. I cannot in-line the video for some reason (does not like the codec used from the conversion, but you can see it in my gallery link.)

post-27864-0-99905900-1461974619_thumb.png

  • Like 3

This evening I made a multi-bank cart that loads an image. Took a little research to figure out how to do it, so I thought I'd share my results in this thread in case anyone else is trying to do the same (after all, what is a good megademo without some nice graphics?) Dithering didn't come out so well, but even convert9918 has its limitations. Anyway, you get the idea.

 

lena.png

LENAC.A99

LENAC.bin

LENAD.A99

LENAD.bin

LENAE.A99

LENAE.bin

  • Like 3

 

Seems to work as advertised. I cannot in-line the video for some reason (does not like the codec used from the conversion, but you can see it in my gallery link.)

attachicon.gifsplitscreen_thumb.png

 

 

Thank you.

Dithering didn't come out so well, but even convert9918 has its limitations.

There are a lot of options to adjust the results of the dither... for something like that which comes out low contrast, try adjusting the luma emphasis, or the color shift. For a quick and dirty result you can also just hit the 'hist' button which does a stretch histogram. ;)

Well, jannone's converter implements the optimal constrained solution using mean squared error in the RGB space, where the constraints are those from the screen mode.

You cannot do better in the sense that using the mean squared error and the RGB space, that is the optimal solution.

 

Naturally, changing metrics and/or color space you can get other optimal constrained solutions.

 

I tried also with perceptually uniform errors

https://sites.google.com/site/ragozini/dithering

it looks better sometimes, but all depends on images and tastes

  • Like 1

There are a lot of options to adjust the results of the dither... for something like that which comes out low contrast, try adjusting the luma emphasis, or the color shift. For a quick and dirty result you can also just hit the 'hist' button which does a stretch histogram. ;)

 

Thanks for the tips.. I'm by no means proficient with the software ;)

Well, jannone's converter implements the optimal constrained solution using mean squared error in the RGB space, where the constraints are those from the screen mode.

You cannot do better in the sense that using the mean squared error and the RGB space, that is the optimal solution.

And mine's a brute force search of every possible combination in your choice of YUV or RGB - no guesswork. ;) I think YUV space converts better than RGB, myself, and I've got options to allow you to balance color versus detail, since the palette is limited. But everyone should try both.

 

Jannone's converter was the one that prompted me to revisit mine years ago.

 

Thanks for the tips.. I'm by no means proficient with the software

I doubt anyone is, it never got much traction. But I've converted tens of thousands of images over the years both for development and just for fun to watch (it has a 'slideshow' mode ;) ). It helps me look for edge cases I can improve, and so I've picked up a few tips.

Hi Guys, short introduction here. I am Ramon de Bruijn also known as RamonB5 of DESiRE. We are a (originally) an Amiga demo group and after short break of 15 years we started doing demos again. But now we target anything we can get our hands on. I guess if you know our name it is probably from the 8088 MPH demo that won Revision last year.

 

I asked orbitaldecay for a new demoscene challenge and he presented me the TI-99/4A.

 

To see all your reactions makes me very happy, so we are not the only two enthusiastic on creating a demo for the TI-99/4A. I am sure if we pull our collective knowledge and spirit together we can make a kick ass demo for this hardware.

  • Like 4

Nice to see you here, Ramon. I am working on getting together a toolchain for building a (up to) 64 bank cartridge. Obviously running Asm994a 64 times is not how we want to build this thing while we're developing it. Currently I'm using xa99 and l99 in a batch script. Attached is what I have so far (just unzip and run make.bat; the .bin files show up in \src\bin).

 

I'm interested in hearing feedback on how I have setup the bank switching mechanism and the build scripts (particularly from people who might be interested in contributing to this). There is a file (MAIN.A99) that gets COPYed into the begining of each bank which contains a NBANK (next bank) function, which will switch to the next bank when called and jump to the end of the common header (stuff in MAIN.A99).

 

Also, there is apparently something I am not understanding about the default bank switching on classic99. When I clear >6000, it switches to bank 0 (in this case LENAC.BIN). When I clear >6002, it switches to bank 1 (in this case LENAD.BIN), but when I clear >6004, it switches to bank 0 again! Why doesn't it switch to bank 2 (i.e. LENAE.BIN)? Do I simply need to modify the .ini to get this to work properly? I am sure there are many bank switching mechanisms in use. Any good links for reading more on this?

Lena.zip

Also, there is apparently something I am not understanding about the default bank switching on classic99. When I clear >6000, it switches to bank 0 (in this case LENAC.BIN). When I clear >6002, it switches to bank 1 (in this case LENAD.BIN), but when I clear >6004, it switches to bank 0 again! Why doesn't it switch to bank 2 (i.e. LENAE.BIN)? Do I simply need to modify the .ini to get this to work properly?

 

Sounds like the typical Extended Basic switching behavior. When you write anything to an address in the cartridge space with A14=0 (6000, 6004, 6008, ...) then you get the first bank, and on writing to 6002, 6006, 600A, you get the second bank. As for Extended Basic, there aren't any more banks to switch.

  • Like 1

 

Sounds like the typical Extended Basic switching behavior. When you write anything to an address in the cartridge space with A14=0 (6000, 6004, 6008, ...) then you get the first bank, and on writing to 6002, 6006, 600A, you get the second bank. As for Extended Basic, there aren't any more banks to switch.

 

Ok, I am loading a cartridge with the Cartridge -> User -> Open dialog. It sounds like that's the default behavior of classic99 and I probably need to modify the ini for it to do something else. I'll read into this and report back for anyone who is wondering.

 

Edit:

I RTFM and dropping the .bin files in the MODS directory and adding the following lines to my INI file does something strange:

[usercart0]
; *** Lena
name="Lena"
rom0=C|6000|2000|mods\lenac.bin
rom1=C|6000|2000|mods\lenad.bin
rom2=C|6000|2000|mods\lenae.bin

Clearing >6000, >6002, or >6004 switches to rom2! Tursi, help! :)

Edited by orbitaldecay

 

Ok, I am loading a cartridge with the Cartridge -> User -> Open dialog. It sounds like that's the default behavior of classic99 and I probably need to modify the ini for it to do something else. I'll read into this and report back for anyone who is wondering.

 

Edit:

I RTFM and dropping the .bin files in the MODS directory and adding the following lines to my INI file does something strange:

[usercart0]
; *** Lena
name="Lena"
rom0=C|6000|2000|mods\lenac.bin
rom1=C|6000|2000|mods\lenad.bin
rom2=C|6000|2000|mods\lenae.bin

Clearing >6000, >6002, or >6004 switches to rom2! Tursi, help! :)

 

I think you need to combine your ROMs into a single file. Call it lena8.bin and Classic99 will know it's a non-inverted cartridge.

  • Like 1

I think you need to combine your ROMs into a single file. Call it lena8.bin and Classic99 will know it's a non-inverted cartridge.

 

Thanks for your help. When I do

copy /b .\src\bin\lenac.bin+.\src\bin\lenad.bin+.\src\bin\lenae.bin .\lena8.bin

and loading lena8.bin with Cartridge -> User -> Open, the option doesn't even show up on the menu. When I add

[usercart0]
; *** Lena
name="Lena"
rom0=C|6000|6000|mods\lena8.bin

to the INI, then clearing >6000, >6002, or >6004 switches to bank 0. :/

Edited by orbitaldecay

 

Thanks for your help. When I do

copy /b .\src\bin\lenac.bin+.\src\bin\lenad.bin+.\src\bin\lenae.bin .\lena8.bin

and loading lena8.bin with Cartridge -> User -> Open, the option doesn't even show up on the menu. When I add

[usercart0]
; *** Lena
name="Lena"
rom0=C|6000|6000|mods\lena8.bin

to the INI, then clearing >6000, >6002, or >6004 switches to bank 0. :/

 

In the ini file the type should be 8 instead of C. And perhaps you need to add an extra bank to make it an even 32K.

  • Like 1

In the ini file the type should be 8 instead of C. And perhaps you need to add an extra bank to make it an even 32K.

 

Thank you again. Is any of this documented anywhere other than the classic99 source code? Neither changing C to 8, nor changing C to 8 and padding the file up to 32K seem to work (in both cases I don't even get a menu option) :(

 

Edit: Also tried

[usercart0]
; *** Lena
name="Lena"
rom0=8|6000|2000|mods\lenac.bin
rom1=8|6000|2000|mods\lenad.bin
rom2=8|6000|2000|mods\lenae.bin

with inverted and non-inverted bank switching to no avail.

 

Edit x2: Nevermind. It appears I made a mistake. The magic words to get the rom running in classic99 are:

copy /b .\src\bin\lenac.bin+.\src\bin\lenad.bin+.\src\bin\lenae.bin+.\src\bin\lenae.bin .\lena8.bin

and load lena8.bin with Catridge -> User -> Open. Notice lenae.bin is added twice to pad up to 32K. Thank you again for your help!

 

Onto the more interesting question: what are your thoughts on the build system and banking code?

Edited by orbitaldecay

Onto the more interesting question: what are your thoughts on the build system and banking code?

 

Assuming you're going to require the 32K memory expansion for the demo, which I think you should, I would move the controller program into the 32K as quickly as possible and from that point on use the cart as a data store from which you can copy data and programs (demo sections) into the 32K. This has the advantage that you can develop the individual sections of the demo as ordinary disk files loaded with editor/assembler.

 

Assuming you're going to require the 32K memory expansion for the demo, which I think you should, I would move the controller program into the 32K as quickly as possible and from that point on use the cart as a data store from which you can copy data and programs (demo sections) into the 32K. This has the advantage that you can develop the individual sections of the demo as ordinary disk files loaded with editor/assembler.

 

Oh duh, great idea. This solves so many of the problems I was thinking about. It's pretty likely that the entirety of the code will fit in the 32K expansion and we can just do bank switching to access the data that's necessary at any given point. I'll start working on some code to do that.

I think it's been covered, but just to be clear, the bank switching captures the address bits when you write to cartridge space (so it doesn't matter if you write a value or clear it). The least significant bit is ignored, because every access becomes two 8-bit accesses. Classic99's naming convention is documented in the PDF manual shipped with the emulator, although it doesn't go into detail on the banking itself.

 

Just to help with the ini, though, when you are specifying type 8 or type 9 in the INI, you actually are providing addresses in EPROM space rather than TI memory space. So your one example should have worked like this:

 

[usercart0]
; *** Lena
name="Lena"
; this would become the first bank on the EPROM
rom0=8|0000|2000|mods\lenac.bin
; this would be the second
rom1=8|2000|2000|mods\lenad.bin
; this would be the third
rom2=8|4000|2000|mods\lenae.bin
And Classic99 would end up with a 32k EPROM (rounding up to the next power of 2) with data in the first 24k and the last 8k unused. Since it's type 8 for non-inverted, >6000 would select the '0000' bank, >6002 the '2000' bank, >6004 the '4000' bank, and >6006 the empty '6000' bank.

 

Sorry it's so obtuse... it's a format that has grown too slowly over far too long a time. :)

 

I took a quick look at the Lena GIF too.. I got good results with the default options in Convert9918A, but the one change I'd recommend is change the "Fill Mode" to "Middle". This makes it zoom the image up to fill the screen and drop the edges ('left/top' and 'bottom/right' crop based on the listed position instead of the middle of the image). Having just a few extra pixels to work with makes a big difference. :)

 

post-12959-0-67116300-1462174505_thumb.png

Edited by Tursi
  • Like 1

 

Assuming you're going to require the 32K memory expansion for the demo, which I think you should, I would move the controller program into the 32K as quickly as possible and from that point on use the cart as a data store from which you can copy data and programs (demo sections) into the 32K. This has the advantage that you can develop the individual sections of the demo as ordinary disk files loaded with editor/assembler.

 

 

Yep, something like this. Either that, or use 8K of the 32K for the actual control routines (which aren't overwritten) and then use the other upper 16K for data in/out of the cart. We've proven that copy routines from ROM to RAM are pretty darn fast by implementing the "copy to 32K and run" cartridges.

 

I know it gets dicey when copying into lower 8K due to other stuff that's expected to be living there, but you might be able to get away with that as well if you can not stomp on whatever's expected to be there.

 

So, bottom line, something like:

 

Lower 8K: Maybe some character sets and other static stuff?

8K >A000, Control program

8K >C000->FFFE, data being copied from cart

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...