Random F18A questions

[matthew180]

Well.... depending on how the 38 or 58 work.

 

If they both have 16K memory and the rest is paged in (that would be what makes it work....) Then your GPU program could scan the registers looking for the page command and do a quick swap. If they both natively have 64K then it's a moot point....

 

It's moot. The 38/58 blow the base address registers out to 17-bits where possible, where on the 9918A the bits would have been 0. There are also two extra registers used to expand the main address register to a full 17-bit for memory access. So the 38/58 can directly address 128K, with an additional 64K that can be paged in at the bottom, for 192K usable VRAM.

 

As far as software goes..... Your going to have to break the ice and break it in a big way. At least provide something for someone to see and go wow...

 

Agreed. It comes down to time though, and not having a lot of extra these days. I'm also not very creative myself, I'm more of a tools-guy. I'm trying to get something out though.

 

[matthew180]

@Kevan: Why not set the poll up here on A.A. as its own thread? I think more people would be inclined to participate if the poll was local to the forum.

[Omega-TI]

@Kevan: Why not set the poll up here on A.A. as its own thread? I think more people would be inclined to participate if the poll was local to the forum.

I suppose I could have, but since this is basically a programing forum, I did not want to step out-of-bounds on what was considered appropriate. Since it does relate to the topic at hand, I thought I'd slip it in.

 

Speaking of polls though, I've discovered they appear to under represent the reality of the situation. Did you see how fast all 10 of the Nan-PEB's went? The number of people wanting F18A's is double that! You might be busy in the near future!

[slinkeey]

Kevan,

 

Well the guy that makes those NanoPEBs does not appear to participate in any forums that I know about. He could be a lurker. So if anything, there might be a ton of people just like him. They share our hobby, but are just not part of the community.

 

Also F18A can be used in more then just the TI-99/4A.

[matthew180]

I suppose I could have, but since this is basically a programing forum, I did not want to step out-of-bounds on what was considered appropriate. Since it does relate to the topic at hand, I thought I'd slip it in.

 

Just poll and post TI related stuff in the A.A. forum. This is not really a "programming" only forum anyway, it is just where Fred put us when it was first set up. Granted most people here do enjoy coding on the TI, but the discussions are pretty much open to anything TI, i.e. programming, games, hardware, emulators, etc. Our community is too small to try and break out a bunch of sub-groups.

 

Speaking of polls though, I've discovered they appear to under represent the reality of the situation. Did you see how fast all 10 of the Nan-PEB's went? The number of people wanting F18A's is double that! You might be busy in the near future!

 

I think the CF7/nano-peb is in more demand for a few reasons. First, the creator never put out an initial "bulk order" to satisfy the initial demand. Second, the creator builds them as they feel like it instead of as people request them. Both of these "stances" is fine, but continues to make the units hard to get. Third, I think the CF7/nano-peb is more useful (and cheaper) than the F18A. Real PEBs are hard to get and cost a lot to ship, and the CF7 solves that problem for people who want to run real hardware. The CF7 also helps transfer files from an emulator environment to real hardware.

 

The F18A is useful, but not required, unlike the 32K and disk system. I also try to keep the F18A available all the time, and in the last year I have yet to experience a "rush" on them. I usually keep around four in stock that will typically sit there for a month or so, then for some reason they will all sell out within a few days or each other. I order more parts and make another batch. I don't see that cycle changing in the near future for any reason.

 

[+retroclouds]

 

 

Both v1.3 and v1.4 firmware support access to the SPI Flash, so any F18A out in the wild would work. That part I did manage to get working the first time.

 

If you want raw brute-force access, i.e. no filesystem and you are going to track wear-leveling yourself, then it would not take much to get it working. Actually, the catalog of "extras" included with the F18A could be used to access stuff added to the Flash, and the routines for accessing the catalog are pre-loaded on the F18A.

 

While the DSR debate has been going on here, I have been looking into flash-based file systems to see what methodologies or algorithms already exist. So far making a systems based on the ideas in YAFFS seem to be where I am leaning, but it will be quite a bit of work.

 

I think a file-system is needed since as more people start to use it (hopefully), then not overwriting data written by someone else becomes critical, i.e. you can't always expect to be able to write to a specific address. But, until then, if you are the only person who actually uses it, you can write anywhere you want. :-)

 

Let me know if you want specific code examples and technical info. I'll write it up, but only if people are serious about actually using it since it is a lot of info to brain-dump.

 

Thanks for the offer. Yeah, I guess it is quite some work. I have some other F18A related stuff I want to experiment with first, so no rush. The problem is, as long as it is not standardized I can only run it on my console. Otherwise I would risk ruining other peoples work.

 

Am mainly focussing on software that runs for the cartridge space.

I was thinking about for example reserving a small amount of flash,e.g. 64K and slice it in 1k pieces. Each slot would be 1k you could use that for storage of things like high scores, game level progress, etc.

Would not use it for temporary stuff.

Thinking about it more, does the F18A also has some RAM that can be accessed from the host or GPU?

[matthew180]

Well, right now I don't think you have to worry about running into data written by anyone else...

 

As for writing to flash, I have found that it is usually done as a "journal" kind of setup where you write key/value pairs. Any writes always go to the next spot in memory, and when you read a value you always start at the bottom and read up to the key you are looking for. That way you always get the most recent value. The challenge is laying a file-system on top of that kind of journal-based writing.

 

The flash used in the F18A can only erase a 64K block or the whole flash. You can write to any byte though, as long as it is empty (i.e. erased). This lack of fine-grain erasing is what makes the whole thing a little more complicated and really requires an abstraction layer to make it easier to use. That's the part I said I would work on, which would simultaneously help in getting the firmware-update code written.

 

The F18A has the original 16K of VRAM, >0000 to >3FFF, which is accessible in the normal way. There is also an extra 2K of RAM that the GPU can directly address from >4000 to >47FF. So the GPU has directly addressable RAM from >0000 to >47FF, plus the VDP registers, palette registers, RNG, counter, and current scan line are also mapped into the GPU address space.

 

VRAM 14-bit, 16K @ >0000 to >3FFF (0011 1111 1111 1111)
GRAM 11-bit, 2K  @ >4000 to >47FF (0100 x111 1111 1111)
PRAM  7-bit, 128 @ >5000 to >5x7F (0101 xxxx x111 1111)
VREG  6-bit, 64  @ >6000 to >6x3F (0110 xxxx xx11 1111)
current scanline @ >7000 to >7xx0 (0111 xxxx xxxx xxx0)
blanking ....... @ >7001 to >7xx1 (0111 xxxx xxxx xxx1)
32-bit counter . @ >8000 to >8xx6 (1000 xxxx xxxx x110)
32-bit rng ..... @ >9000 to >9xx6 (1001 xxxx xxxx x110)
F18A version ... @ >A000 to >Axxx (1010 xxxx xxxx xxxx)
GPU status data  @ >B000 to >Bxxx (1011 xxxx xxxx xxxx)

 

VRAM = VDP RAM - byte/word addressable

GRAM = GPU RAM - byte/word addressable

PRAM = Palette RAM (the palette registers look like 16-bit values in RAM and are word addressable only)

VREG = VDP Registers, byte/word addressable

current scanline - read only

blanking - read only

RNG and counter - specific use for init, start, stop, reset

Version - read only

Status - write only, 7 least significant bits, goes to an enhanced status register for the host CPU to read

 

[+OLD CS1]

Reading about the DSRs and address space made my head spin while thinking about what might be a neat option for the F18A. On the Amiga, most of our modern Zorro expansion cards include flash memory which can be used to load modules which would normally have to be loaded after the OS boots, like patches or replacements for system libraries, USB drivers, etc. Does the F18A have the ability to expose itself in such a way as to provide "boot" options, like a favorite game or cartridge (non-GROM) or disk loader?

 

Anyway... I checked CHC... no F18As in stock I missed the boat!

[matthew180]

You didn't miss the boat, it sails every time I run out and have a weekend to build a few more. I feel like a broken record (I keeping saying this it seems), but my intent is to build them as the demand dictates. I typically make about four boards and put them up on the store. They sit there for a month or two, then sell out in a day for some reason. Then I order some more parts and make a few more. I'm going to make four today in fact, so if you want one, they will be up later tonight.

 

As for exposing itself, the F18A can only do what the original VDP could do as far as the interface to the host system is concerned.

[+OLD CS1]

As for exposing itself, the F18A can only do what the original VDP could do as far as the interface to the host system is concerned.

 

I assume, then, that the VDP does not. Bummer.

[mnbvcxz]

Hi, Matthew, I am thinking about installing the internal 16 bit ram mod, if I used 32KB chips I could have up to 64KB of 16-bit ram (with some addressing modifications).

If I disabled the GPL roms, could the F18A act as a "bootloader" copying the GPL code, on reset, from its flash rom into the 16-bit ram, then I would have the option of overwriting the GPL interpreter with a monitor/DOS to use the machine almost like any other computer.

It would take a lot of work, but if the F18A can be a bootloader, then I will give it a try.

Edited August 23, 2013 by mnbvcxz

[Tursi]

I'm not Matthew, but, the F18A doesn't have access to the 9900 memory space. That said, you might be able to achieve a similar effect if you replace the 9900's ROM (which you would have to do to run GPL from RAM anyway) and make THAT download the code from the F18A. You'd be free to do anything, then, and the only hardware modification required would be the ROM replacement (and maybe removing the GROMs, but you probably don't have to).

[mnbvcxz]

I'm not Matthew, but, the F18A doesn't have access to the 9900 memory space.

 

Yes, I realised that after posting, but Matthew could tell me if the F18A can hold a program in flash to execute on reset, then begin sending the new OS.

Then some DMA mechanism will load the OS into ram.

 

That said, you might be able to achieve a similar effect if you replace the 9900's ROM (which you would have to do to run GPL from RAM anyway) and make THAT download the code from the F18A. You'd be free to do anything, then, and the only hardware modification required would be the ROM replacement (and maybe removing the GROMs, but you probably don't have to).

 

I'm not sure what you are saying here, I intend to disable the roms and replace them with ram, so the roms cannot do anything.

I may end up copying the roms to high memory, switching out the roms, switching in the lower ram and jumping to the start of the new OS. but it is really more hardware than I would like.

Edited August 23, 2013 by mnbvcxz

[Tursi]

I'm not sure what you are saying here, I intend to disable the roms and replace them with ram, so the roms cannot do anything.

I may end up copying the roms to high memory, switching out the roms, switching in the lower ram and jumping to the start of the new OS. but it is really more hardware than I would like.

 

No matter what code you load on the F18A, the 9900 is in control of the rest of the machine and so it must have some code to exectute at reset. You can't completely replace the ROMs with RAM. Also.. the GROMs are a different device than the ROM -- GROMs are a memory mapped device and the ROMs map into the 9900's memory space. Worse, it is not possible to DMA to any memory in the 9900 memory space without reworking a few traces on the motherboard - the lines that would otherwise tri-state the 9900 are tied permanently, so it is always driving the address bus and owns the data bus.

 

From the software side, in a standard machine, at powerup the ROM code initializes a few memory locations, and then jumps into the GPL interpreter which occupies most of the ROM. The GPL interpreter then loads and exectutes the GPL code stored in the GROMs. This GPL code is responsible for all the rest of the hardware initialization.

 

The minimum system that I can see that will do what you describe replaces the ROM with a bootloader that uses the F18A to download the program to your RAM and then executes it. But either way you will need code on the 9900 to start things up. Alternately, this is also possible to do in GPL, but then you need the CPU ROM to remain present to run the interpreter.

[mnbvcxz]

Well if DMA is not possible, it will take some thought to come up with another way of installing a new OS.

It may be easier to start from scratch and build a single board computer with 16 bit ram and an F18A.

[Asmusr]

Sounds like a fun project, but you would need to maintain some degree of backwards compatibility with existing software, or the new computer would be very lonely.

[Omega-TI]

Awhile back Tursi posted a program called TMS9918A Converter for Windoze that takes graphics and converts them for display on the TI. My problem is I cannot remember the name of the program, or where to get it that displays the "Scanline Palette Bitmap F18A" images.

 

Could someone please guide this old forgetful man to the right place. Thanks!

[Tursi]

http://harmlesslion.com/software/convert9918

[Omega-TI]

http://harmlesslion.com/software/convert9918

 

I need to start proof reading my posts for clarity! Thank's Tursi, I actually already have THAT program. What I need is a program for the TI that will display the enhanced images. Can you help with that?

[Tursi]

I never wrote such a thing, just a demo application with a bunch of hard coded pictures. There's sample code included with the program to incorporate into your own software... and ISTR that someone /did/ make a gcc-based viewer, it's on here somewhere. have you tried a forum search?

[Omega-TI]

I never wrote such a thing, just a demo application with a bunch of hard coded pictures. There's sample code included with the program to incorporate into your own software... and ISTR that someone /did/ make a gcc-based viewer, it's on here somewhere. have you tried a forum search?

 

Well I'll be damned! You've written so many awesome programs, I guess I just assumed you wrote one!

 

Oh well, I have so much on my plate right now anyway that I'll put that on the back burner for now.

 

It would be real cool to have a slide-show program to display those enhanced graphics that your converter makes ,and that Matthew's magical F18A can display.

[RobertLM78]

Now that I have an F18A, I'm a little curious whether anyone knows or has tried Beyond WordWriter (by DataBioTics) with it. Of course, I can find out for myself once I get it installed, but for the mean time I thought I'd ask .

[RobertLM78]

Now that I have an F18A, I'm a little curious whether anyone knows or has tried Beyond WordWriter (by DataBioTics) with it. Of course, I can find out for myself once I get it installed, but for the mean time I thought I'd ask .

Well, I couldn't help myself once I realized how easy it would be to upgrade the video processor - it took probably an hour, including case modifications, to install. That said, I snapped to the fact that in order for a program to take advantage of 80-column capabilities, it would have to be written for such a device - so I obviously withdrawl this question.

 

Anyway - it looks absolutely fantastic! Thank you again Matthew!

 

 

Edited November 12, 2013 by RobertLM78

[RXB]

Hi, Matthew, I am thinking about installing the internal 16 bit ram mod, if I used 32KB chips I could have up to 64KB of 16-bit ram (with some addressing modifications).

If I disabled the GPL roms, could the F18A act as a "bootloader" copying the GPL code, on reset, from its flash rom into the 16-bit ram, then I would have the option of overwriting the GPL interpreter with a monitor/DOS to use the machine almost like any other computer.

It would take a lot of work, but if the F18A can be a bootloader, then I will give it a try.

 

A issue as resulted in that GPL stands for Graphics Programming Language and GPU of the F18 has assumed the same 3 letter designation so confusion is the result long term.

 

Secondly GRAM was used also for the F18 and confusion again results as for 30 years GRAM has stood for Graphics Random Access Memory but the F18 uses the same destination for GPU RAM.

 

Using the same accronyms for a new device when the standards are already set is going to really create confusions long term.

 

GPURAM should have been used and GPUPL should have been used as that is more descriptive and less confusing long term. Then co opting currently long time used abbreviations.

Edited November 12, 2013 by RXB

[+OLD CS1]

 

Secondly GRAM was used also for the F18 and confusion again results as for 30 years GRAM has stood for Graphics Random Access Memory but the F18 uses the same destination for GPU RAM.

 

Using the same accronyms for a new device when the standards are already set is going to really create confusions long term.

 

GPURAM should have been used and GPUPL should have been used as that is more descriptive and less confusing long term. Then co opting currently long time used abbreviations.

 

Long time standard for whom? Remember, the industry left us behind a long time ago, and GRAM and GPU mean different things outside of the community. The F18A was developed in the outside world and while the device is aimed at the community a compromise could have been made, the acronyms do fit the "new" standard and it is already done. We could just as easily prefix GRAM and GPU with F18, making them F18-GRAM and F18-GPU.