Geneve OS development discussion

[+9640News]

1 hour ago, GDMike said:

How would I make this show up on boot? Sorry, im still learning....

A couple of thoughts here.

 

If you are referring to the graphic on the boot eprom screen, then you need to make the graphic compatible with the existing code, and it needs to fit inside of 8K in the second 8K bank of the Eprom.  The existing code that processes the existing 8K image exists in the first 8K of the boot eprom.  I've not seen any actual code to know what the graphic format, or if it is a new format, the original swan was in.  It is a rather small subroutine for processing the video stored in the second 8K bank so it may make sense to disassemble to figure out what you need, etc.

 

Now, if you want to display it from an AUTOEXEC,  then as Nick said, convert it to MyArt.  I know on Mytbox99.ddns.net:61643, there is a program that creates a script of graphic files that can be displayed with Picture Transfer.  You should be able to use the graphic in native format if it is GIF or Myart without converting the image. 

 

Finally, the last option is to convert it to Myart.  If you find my BIBLE source code, it has all the source code to process a MyArt image.  You could either embed the file as DATA statements in your own program, or use the source as the starting point and either pass a command line argument to the graphic you want to display.  

 

I haven't seen any source code for processing a GIF image nor have I seen any code to process a JPG format file.  If someone has such code, then I would be interested in it myself.

 

Beery

 

[+FarmerPotato]

1 hour ago, 9640News said:

 

I haven't seen any source code for processing a GIF image nor have I seen any code to process a JPG format file.  If someone has such code, then I would be interested in it myself.

 

Beery

 

I want to bring us PNG decoding. It commonly uses Zlib for compression, which is open source. I get around 6.4K file size from the geneve swan 256x192 G7 image (256 color). Some photos with more colors have been coming in at 8.8k. 
 

getting Zlib into assembly is the tough part. I have a Forth version that is just two screenful though! 
 

 

[+mizapf]

3 hours ago, GDMike said:

How would I make this show up on boot? Sorry, im still learning....

The boot EPROM contains some code to paint the MyArt-formatted Swan picture on screen. If you want a different picture, you could either use my loader and add a suitable picture loader together with the desired picture, or you have to use a different boot EPROM - or use PFM and design a custom loader. The easiest thing would be to copy the 0.98 boot EPROM into the PFM and replace the picture data.

[GDMike]

17 minutes ago, mizapf said:

The boot EPROM contains some code to paint the MyArt-formatted Swan picture on screen. If you want a different picture, you could either use my loader and add a suitable picture loader together with the desired picture, or you have to use a different boot EPROM - or use PFM and design a custom loader. The easiest thing would be to copy the 0.98 boot EPROM into the PFM and replace the picture data.

Huh? The easiest thing to do, copy .98 boot eprom into the PFM. What is PFM?

Thx

[+9640News]

PFM - It is something "Pretty F...ing Magic".

 

Something no longer available that was a modification that added memory 384K to 512K plus a custom boot loader replacing the Eprom.  Required trace cuts, wiring, and more.  I'm not 100% certain, but I do not think @Shift838 PCB he is working on will serve PFM operability.

 

Beery

[+arcadeshopper]

Huh? The easiest thing to do, copy .98 boot eprom into the PFM. What is PFM?
Thx

You don't have one.

Sent from my LM-V600 using Tapatalk

[GDMike]

So far, I'm ouuta magic

[+mizapf]

Programmable Flash Memory

Ehm ... I added PFM in different variants to the MAME emulation (PFM, PFM+, PFM512), but it turns out only a few people actually have it? I hoped it is at least feasible to rebuild it.

 

See line 116ff in https://github.com/mamedev/mame/blob/master/src/mame/drivers/geneve.cpp

[+InsaneMultitasker]

Most of these recent topics aren't going to be addressed by the OS development effort. Beery and I would be too busy. 

 

PFM stands for one thing to the creator and another to the consumer.  I'll let your imagination run wild.  The mod can be performed as long as the right flash chip is used. 

 

[+9640News]

14 minutes ago, mizapf said:

Programmable Flash Memory

Ehm ... I added PFM in different variants to the MAME emulation (PFM, PFM+, PFM512), but it turns out only a few people actually have it? I hoped it is at least feasible to rebuild it.

 

See line 116ff in https://github.com/mamedev/mame/blob/master/src/mame/drivers/geneve.cpp

I've got one PFM myself.  The PFM support may make it possible to test reprogramming it within MAME.

[+Schmitzi]

 

I have a PFM one too, but I never touched that PFM-config because I´m just happy that it works.

It´s on my plan to learn about, just to handle it. Maybe

[+Ksarul]

On 3/2/2021 at 6:30 PM, InsaneMultitasker said:

we might need to create or necro a SID topic soon...

 

Yeah, I have a batch of bare SID boards in my basement right now that I need to validate. . .along with some PEB Extender boards. Now I just have to dig my 60-pin connectors out again. . .

[+InsaneMultitasker]

The Geneve OS low level routines and ramdisk formatter have been updated:  the ramHD partition size is no longer hard-coded.   The OS can now manage a maximum ramHD partition of ~63,488 sectors (31 bitmap sectors * 256 bytes/sector * 8 bits/byte * 1AU/bit * 1sector/AU = 63488 sectors).   This is nearly double the currently available physical implementation since the in-use single-layer boards are populated with 8MB of SRAM.   Picture is my 8MB ramdisk formatted to maximum capacity, no DSK partition.

 

[RickyDean]

22 minutes ago, InsaneMultitasker said:

The Geneve OS low level routines and ramdisk formatter have been updated:  the ramHD partition size is no longer hard-coded.   The OS can now manage a maximum ramHD partition of ~63,488 sectors (31 bitmap sectors * 256 bytes/sector * 8 bits/byte * 1AU/bit * 1sector/AU = 63488 sectors).   This is nearly double the currently available physical implementation since the in-use single-layer boards are populated with 8MB of SRAM.   Picture is my 8MB ramdisk formatted to maximum capacity, no DSK partition.

 

That is great news, I know my 3 horizon 4000(b)' s will be maxed out.

[+InsaneMultitasker]

I have to give this some thought before I pursue any further... 

 

[+9640News]

Interesting use of the TTYOUT routine to the parallel port.  Implement an inbound scan on the port, and one could run text based programs from a terminal.  

 

Beery

[+InsaneMultitasker]

Yes, good eye.  TTYOUT and the keyscan XOP are tied to the serial port to provide a pseudo-remote terminal experience, however, I ran into a problem with interrupts so I had to disable the input for now.   The above screenshot was me running the ramdisk configuration program remotely from my PC via Hyperterminal - no Geneve keyboard interaction. 

[+9640News]

11 hours ago, InsaneMultitasker said:

Yes, good eye.  TTYOUT and the keyscan XOP are tied to the serial port to provide a pseudo-remote terminal experience, however, I ran into a problem with interrupts so I had to disable the input for now.   The above screenshot was me running the ramdisk configuration program remotely from my PC via Hyperterminal - no Geneve keyboard interaction. 

Hmmm, .... and I think the TIPI XOP can be queried within the keyscan XOP which could allow remote TCP access as a third key input source.  I would have to double check some very old Windows code I wrote to confirm, but I think that is possible.

 

 

 

[+InsaneMultitasker]

3 hours ago, 9640News said:

Hmmm, .... and I think the TIPI XOP can be queried within the keyscan XOP which could allow remote TCP access as a third key input source.  I would have to double check some very old Windows code I wrote to confirm, but I think that is possible.

 

 

 

That would be interesting as well.  I started looking into this because command line programs don't echo into the scroll-back buffer, and I wanted to be able to see what happened with the OS assembly process without watching it for 5 minutes straight.  Using PUTTY to access the RPi got me thinking that maybe we could do something similar to attach to the Geneve console, even if it was the same session as what you see at the keyboard.  Now, anything that uses direct video writes won't work but any program that uses the command line is visible in the terminal.  The keyboard input will need some sort of interpreter, especially if ANSI up/down/right/left arrows are used, which is why I'm not sure how far to take this.  Right now it is a glorified command line logging tool. 

[+InsaneMultitasker]

Now we're getting into deep, scary territory.  Doubled allowable SCSx devices from 3 to 6.   The DSR table is currently AORG limited and as usual, some regression testing is required.  At minimum, this will now allow someone with a SCSI2SD device (with 4 partitions) to access them without remapping, and room to also have a ramHD partition or two.  As shown in the picture, I mapped the Horizon at >1600 to device SCS6. (hmm, either my battery is close to dying or I wrote this code 6 hours into the future)

 

[+9640News]

15 hours ago, InsaneMultitasker said:

That would be interesting as well.  I started looking into this because command line programs don't echo into the scroll-back buffer, and I wanted to be able to see what happened with the OS assembly process without watching it for 5 minutes straight.  Using PUTTY to access the RPi got me thinking that maybe we could do something similar to attach to the Geneve console, even if it was the same session as what you see at the keyboard.  Now, anything that uses direct video writes won't work but any program that uses the command line is visible in the terminal.  The keyboard input will need some sort of interpreter, especially if ANSI up/down/right/left arrows are used, which is why I'm not sure how far to take this.  Right now it is a glorified command line logging tool. 

Not sure how many keys HyperTerminal sends out if you use a up/down/right/left response to know if it is a multibyte ANSI style sequence or to detect a function keypress.  That would need a pretty elaborate keyscan routine embedded into the existing "elaborate" MDOS keyboard scanning routine for all the various keyboard modes.  Not anything we would need/want to do now, but I think one would need a MDOS command to toggle TIPI Keyboard Input to set a flag in L6\KEY1S.  From there, I think a program running with the use of TTYOUT would test the flag, with the TIPI XOP Keyscan routine (new opcode in the TIPI XOP) would adjust the bytes in L6\KEY1S for the KEYSDN an KEYFLG tables as needed.  One would probably just page in that page of the XOP, and put most of the code to toggle those tables in the TIPI XOP.

 

The big issue is if it is a multi-byte input, is having the TIPI turn off interrupts until a specific keypress is built, so that interrupts could then be turned back on for the running MDOS program to then scan.  Would not want to have only a partial key assembled if it is a multi-byte.

 

Makes my head spin a bit.........

 

Beery

 

 

Beery

 

[GDMike]

On another similar but not the same topic

But inquiring minds want to know. Lol, is tipi available yet to geneve in straight up MDOS mode only. 

And I assume it would be a prom change??

But I'm just looking for the latest news, or is this idea on a back burner burner..

Ty

[+9640News]

I have a version of the eprom that will boot if there is a floppy or myarc hfdc in the PEBox that will allow booting from the TIPI.  I hit a roadblock trying to use that same eprom code to permit booting from IDE, and SCSI eprom booting has not been tested yet.

 

I just got the latest updates for the HRD for 8 MB use and the additional SCSMAP'ing capability.  I think the next step is to confirm the IDE code has no issues, and likely we will be close to a beta release for feedback.  I'm using the newest code exclusively and haven't identified any issues thus far.

 

Beery

 

[GDMike]

Ok.. sorry for the interuption. Now I understand whenever I read the last post. I'm just trying to follow.. exciting..

[+InsaneMultitasker]

Even with real life incessantly knocking at the door, there has been a lot of activity during the past few weeks.  Testing has uncovered a few longstanding bugs and some ideas to further protect data integrity. 

 

March 1-28

1. Title/Version screen updated with redefined graphics. [htitles]

2. IBM Graphics enabled at startup [l6\xops-s]

3. MODE RS232 updated with 38,400bps option  (l8\rsd2-s, cli\modes)

4. EXEC option 5 loader updated. Bugfixes with memory map, cleaned up powerup routines, tied into new OS powerup for maximum file reset

5. GPL/TIMODE updated and tested.  

6. GENCFG ramdisk configuration program moved to final testing.  RamHD low level code updated to use the new partition header.

   a) format with disk and/or ramHD partition

   b) detection routines complete

   c) user validation routines added

7. Issue:  Possible bug in floppy bitmap allocation routine when requesting a sector at the boundary/last bit in the bitmap. Unable to completely use all space on the ramdisk and/or corruption. 

8. Issue:  Executing a batch file that loops a single program triggers a memory node leak after 250+ iterations that eventually ends in 0 available memory pages.  I noticed this problem long ago in MESS and thought it was an emulation issue, now I believe it is a bug that rarely presents itself because we often perform warm restarts.  

9. Maximum SCSx devices extended from  3 to 6, with the possibility of increasing to 9 with further changes to SCSMAP and the device caching.   (HD\WINDS1-S, SCSI\BUFEQU2, SECTOR_S, L8\HDR1-P2)

10. SCSMAP updated to account for SCS4,SCS5,SCS6.  (CLI\newcmds, scsi2\sector_s)

11. IDE low level support tested and validated in MAME.  There are two revisions from 2019: TIDE5 and TIDE8.  Decision made to use TIDE8.  

12. Mapping for IDE1-IDE8 added to the low level support.  Testing is in progress.  (cli\newcmds, scsi2\sector_s, tide8s)

13. Horizon ramdisk ramHD software addressing capacity increased to ~65,530 sectors.  Current hardware only populates a single layer at 8MB capacity.  16MB was tested in MAME. 

14. Autoexec routines updated to detect boot from IDE, SCS, TIPI  (cli\batcmds)

15. Issue:  MakeDir (MD) on a nonexistant SCS device generates the wrong error "Dir not empty"; the SCSI low level driver is reporting an error inconsistent with the HFDC.  (see l8\fileops:comdir)

16. Risk:  SCS, IDE, and RamHD device mappings may be changed by the user at any time.  The disk parameters for each device are cached in memory during powerup. If the mapping changes without a powerup, the newly mapped drive will be accessed using the previous device's parameters.   Researching how to best invalidate the parameters to force the DSR to re-cache for the newly mapped drive.

17. MEMORY and TELNET commands added to CLI (multiple files affected)

18. Created GenWIPE tool.   Allocates all available memory and clears it.  Used immediately prior to LINKing the OS object files. Added to !MAKEFILE for OS creation.  Spurred by question/concern from @mizapf

19. To do: remove ramdisk CRU selections 1800 and 1900 from remap table. Physical hardware does not allow these addresses.

20. To do: research CAPS lock inconsistent behavior on warm restart

21. WARNING: When setting up the Horizon ramdisk, do NOT use the Phoenix selections for 1400/1600 CRU.  These are NOT supported. The Phoenix option was deprecated in 1990. 

22. PFM device support utilities and testing under way as a tacit prerequisite to adding OS powerup routines for the TIPI, SCSI, and IDE cards.  The PFM devices as-is can only store 120K of the OS, meaning the TIPI and SCSI/IDE/RamHD routines must be loaded externally.  A powerup cannot occur until the code is loaded into the OS memory. 

23. Carryover from February:

a) Bug: Internal ramdisk is not always initialized when re-created after TIMODE/TIMODE2 batch file. 
b) Research: [DSRPASS-S] heavily AORG'd with no boundary protection. Review for code overlap/data corruption.

24. Memory powerup now identifies  384K memory upgrade as slow Ram (l7\manage2s, l7\manage2s)

25. Resolved date/timestamp error; With the HFDC and similar peripherals, the seconds value is always even as a result of being divided/multiplied by 2.  The TIPI seconds value is either odd or even. Correction required to account for the Lsbit being set (cli\getcats)

26. EVEN