Horizon RAMdisk ROS and CFG Development

[HOME AUTOMATION]

I thought the observations might help overcome any compatibility issues during power-up.

 

Didn't mean to have a conversation with myself.

 

     Soggy.

[+InsaneMultitasker]

All good, sometimes hard to connect the dots in these threads    Was thinking a a powerup thread could help anyone that is dealing with similar problems and improve upon based on what you are observing/learning. 

[+InsaneMultitasker]

On 4/6/2020 at 1:07 PM, InsaneMultitasker said:

As we get closer to more hardware being released and more interest in the ramdisk,  there is now a Github site in process for the source code and other materials.  A Wiki has also been created to cover things at a high level. I posted this in the HRD4000B topic as well.

 

Wiki:

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/wiki

 

Source:

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a

 

Since it was asked of me:  

1. Yes, I intend to post the Geneve ramdisk formatter source in this repository. 

2. The CRC installer program will not be publicly posted.

[+Schmitzi]

On 4/5/2020 at 9:33 PM, HOME AUTOMATION said:

[...]

The .bin G. and C. images of this cart have been intentionally kept short, to keep wait time down. While the cartridge BOOTS/RAM loads, a BUS on the TI becomes unstable.

[...]
 

Hi, sorry, but for me, I didn´t see your 2 posts, as I think I jumped over by clicking this AA-notiifications.

 

Talking of short images names, that meet some thoughts I had. My impressions to FG99 was, while testing the new ROS,

that if the SD-card is very full, it takes some more time to load the menu/files for building the startup screen ?
So, if I power up the TI and immediatly press this "any key" to begin ?, maybe the files were not completely read,
as I saw that some entries still are missing in the startmenu... Otherwise, powering up and waiting i.e. 30 seconds,

then the menu shown is complete (because all files were read?), ==> all images are succsessfully shown...

What I want to say here, hopefully not hijacking the topic for FG99-things,
as - if the PowerUp routine from the HRD is set to ON, maybe it jumps over the start screen immediately

and brings up the LBSoD ("Light Blue Screen of Death©"),  (not only because of missing the menu739-file ?),
maybe this somehow is also related to other start-up issues, on the bus or so ? (Because other hardware also needs time?)

Just saying, to give food for any thoughts, generally.

thanks

 

Edited April 8, 2020 by Schmitzi

[atrax27407]

I don't think that the auto-boot "jumps over" the start screen. I have noticed that, when auto-boot is ON (and MENU is present), you get a very brief glimpse of the title screen before MENU is displayed. With no MENU available, you get the error condition of the LBSoD since it can't load something that is not there.

[+InsaneMultitasker]

I tried to induce the LBSoD  (lol Schmitzi) again last night and could not trigger it. I know it used to happen for me, now it doesn't, and I didn't change anything that I am aware of.

 

Atrax, are you able to force this to happen on your system?  

[atrax27407]

I have NOT been able to induce the LBSoD on my system either. With MENU absent, if auto-boot is on, my system defaults to either the cartridge in the cart port or (if there is no cartridge inserted) to the title screen. I surmise that Schmitzi must have either a Final GROM or UberGROM in the cartridge port which possibly causes the LBSoD.

[+InsaneMultitasker]

ok thanks.  I have an ubergrom with XB27 installed and it doesn't give me the LBSoD anymore.  I have no good reason for the change though. 

[atrax27407]

It would presumably default to XB 2.7 without MENU being present - likely a cyan screen with a blinking cursor (or whatever screen display is present with XB 2.7).

[HOME AUTOMATION]

  "Q" is back!

 

So... I worked on this some more last night. I had previously added code to change >83D4, back to the more common default, >E0, this restored the display after the next key-press. Now I've added code to change VDP REGISTER 1 to >E0 as well. This restores the display w/o having to press a key first! I had to write my code over the FGROM's MENU's graphics definitions a bit or two. So, the power-up routine I'm using is on the FGROM and points to The FGROM's menu, To my chagrin somewhat, the TITLE SCREEN does flash on for just an instant! I don't recall ever noticing that behavior before. If anyone knows how to send a key-press from assembly ...I would appreciate directions. Oh, I went out shopping today... so this could be, my Finalpost.

Edited April 8, 2020 by HOME AUTOMATION

[+InsaneMultitasker]

Has anyone asked Ralph?

[+InsaneMultitasker]

Here's the little title program I put together to display a TI Artist picture at powerup.  It is hardcoded to load the picture files (TITLE_C and TITLE_P) from DSK5.  You can sector edit the name (and file length) if you so choose.

 

The image will display for approximately 5 seconds. you can bypass by pressing the spacebar.

 

To make this auto-load in place of MENU, go into CFG, Edit the options, and set Len/Name for the first two as follows:

Change first item to TITLE (length 5)

Change second item to MENU  (length 4)

 

Copy the contents of the ZIP file to DSK5. (this assumes DSK5. is the FIRST ramdisk in your system)

 

Restart and if all goes well the picture will display.  The TITLE program looks for MENU in the CFG calls. If it isn't there, you may get stuck in an endless loop.

 

TITLE-AUTO.zip

 

[HOME AUTOMATION]

I've considered contacting ralphb about my interests, but I'm not officially working on anything right now, and don't want engage him needlessly, as I imagine he keeps pretty busy and I am sure I'll want his help(again) at some point. Besides, I don't want him to kick my ask for messing around in his code!(surely I jest:)

[+InsaneMultitasker]

So tonight I re-learned something... KSCAN needs to know the "keyboard" number in location 0x8374.  Seems that when the powerup takes control, there is no prior value, and I was incorrectly setting the value to 0x00 (old XB habit) instead of 0x05.  Sigh.  Anyway, two people who tried the program reached out to me so I will let them test before I update the ZIP.  (This program was something fun that I created and really didn't do much testing!). 

 

Edit: also noticed that I was using VRAM 0x3800 and above for PAB and buffers and color table info.  Thus it is possible the program would - for people using certain disk controllers - trash the VDP identification header and a portion of the disk buffers.  I fixed that by saving VRAM to a temporary location and restoring prior to launching the menu.  I also added file error trapping so that the program launches MENU if either _P or _C file is not found.  

 

 

[+Schmitzi]

 

So, let´s get ready to Rambo

 

TITLE works good now, HRD16 boots up clear, XB2.7 and FinalGROM´99 too ?

 

Hoping for final update soon. Thx to InsaneMultitasker !!!

 

 

 

 

[+Schmitzi]

 

That´s how the FinalGROM´99 finally boots. Looks somehow strange, but seems to work

 

 

[+InsaneMultitasker]

ROS tries to automatically launch the cartridge in the slot.  I wonder if for autostart ON this should be configurable to avoid some of the difficulties we face.  I'll add this as a research item for future. 

[HOME AUTOMATION]

 Sounds like a possible feature!

 

This is the part of the thread, where I attempt to Apologize(to all) for my shortsightedness/stubbornness. Though my observations led me to a solution, the breadth of my conclusions appear to have been false/misgiven. Further investigation suggests; >E0 is NOT a default value after a power-up routine.

So, hmm, considering all, the only thing I really found at fault with the FGROM, was: My own speculations(powered by intrigue). Looks like the darn thing works flawlessly!

 

Although the subject of cartridge power-up, was meant to be adjunctive. I see now, how it seemed off-topic.

 

I hope I have merely been an annoyance, and have not really offended anyone! Just inspired to help ...maybe a little too much.

 

    Alex

[+InsaneMultitasker]

Nah, I would have to imagine that few if anyone  feels there is a need for any apologies.  None of us knows everything and some of us even have to re-learn things.     Yes, we sometimes get off topic but it usually comes back around in the end. 

[+InsaneMultitasker]

TITLE source (originally SPLASHscreen) has been uploaded to the Horizonramdisk GitHub repository.
I cleaned up a few things in the code and allow spacebar to bypass before the picture load starts.  "final" version is being tested. 

 

[atrax27407]

The "final" version works great!

[+InsaneMultitasker]

Been playing with MSX screen converter  V9938 images - https://msx.jannone.org/conv/ 

 

the below two images are 512x212 256 x 16 color as displayed on the Geneve (emulation).  The images are saved as a raw program image file of 212 sectors, exactly as generated by the web site.   Since the Geneve OS is able to load more than 16K directly into VDP the decision and code were fairly easy. The palette is the only problem; the converter provides the palette bytes separately so I had to type it into the program by hand.

 

The v9938 256x212 converted image was similar in quality to the F18A mode and if I recall correctly, the v9938 graphics mode allows each pixel to be set with an 8-bit palette (this is how I converted the images from Rasmus demo a few years back).

 

I'm not committing to a v9938 version of TITLE; first I need to sort out the file IO and whether or not I want to muck around with record IO and/or direct input on the TI, and how I'd deal with the palette. 

 

And an old image of Bud Mills doing something that was NOT ti specific - prayer care packages for troops.

 

[atrax27407]

A v9938 system with 192K of VRAM would be equally as impressive - I hope!

[+InsaneMultitasker]

2 hours ago, atrax27407 said:

A v9938 system with 192K of VRAM would be equally as impressive - I hope!

Geneve uses the V9938 so there would be no difference visually.  The data file is the raw information loaded directly into VRAM.  Unlike GIF or Myart format, there is no compression and no manipulation, just a dump-and-display.  I willl compare the color depth vs. resolution later this week. 

[+InsaneMultitasker]

A few mode 7 (256 x 212 x 256 color) images on the V9938/Geneve using the same MSX converter.  Files are still 212 sectors. The second one wrapped for some reason but the overall image looks pretty good.  If I pursue this much further I will create a separate topic.