Geneve OS development discussion

[+InsaneMultitasker]

@mizapf, do you recall writing a program to test whether or not pages >C0->E7 respond (should be classified) as slow or fast RAM?

 

Back in the 90s I modified the memory list initialization routine to track the above pages as fast RAM, meaning that they are incorporated into the same memory list as pages >E8->EF. 

 

@9640Newsand I have been digging into the Geneve OS memory XOP routines to track down a few problems with shared memory and system node de-allocation.  I came across a few forgotten (documented) changes I had made to the system XOP calls for the "384k fast ram" modification.

 

If the >C0->E7 range is truly equivalent to the slow DRAM pages, I think the "384k" modifications to the OS should be undone.  I would like to verify speeds and operation once more on real hardware before committing to changing the OS.

[+mizapf]

Had to do some research, but you may have my Genmod test program in mind, which runs loops in various banks. See attached. The value 110 means 1 wait state (11 seconds), 100 means 0 wait states (10 seconds).

 

I also put the source code on that disk; you may easily adapt it. You just need to check the COPY path at the end.

timing4.dsk

[+InsaneMultitasker]

5 hours ago, mizapf said:

Had to do some research, but you may have my Genmod test program in mind, which runs loops in various banks. See attached. The value 110 means 1 wait state (11 seconds), 100 means 0 wait states (10 seconds).

 

I also put the source code on that disk; you may easily adapt it. You just need to check the COPY path at the end.

timing4.dsk 180 kB · 3 downloads

Yes, thank you.  I will run your program this weekend.  I just need to figure out where I safely placed my 384K-modified Geneve!!

[+InsaneMultitasker]

On 1/28/2022 at 6:05 PM, mizapf said:

Had to do some research, but you may have my Genmod test program in mind, which runs loops in various banks. See attached. The value 110 means 1 wait state (11 seconds), 100 means 0 wait states (10 seconds).

 

I also put the source code on that disk; you may easily adapt it. You just need to check the COPY path at the end.

timing4.dsk 180 kB · 6 downloads

I ran the program on my standard development Geneve (512K DRAM, 64K SRAM) and a Geneve modified with the 384K SRAM at pages >C0 to >EF.  

 

Both systems produced the same results:  Pages >E8 and >EC reported values of 100, all other pages reported 110.  

 

I will review the program code to be sure I have no questions, however, based on the results I am now inclined to change (correct) the MDOS memory management routines to treat pages >C0 to >E7 as 1 wait state "slow" RAM.  

[+mizapf]

There is actually nothing at the Gate array that could indicate some special handling of the other banks. You have RAMEN and RAMENX, each one activating one SRAM chip. Maybe there was an early idea of this bigger SRAM area, still shown in the manuals, but later, only the well-known EC-EF, and as expansion, E8-EB remained.

 

And the test program should be correct, you can use a stop watch to verify it. The 1-wait state access runs exactly one second longer than the 0-wait state access. Or you add some more loop iterations to make it clearer.

[+InsaneMultitasker]

6 minutes ago, mizapf said:

There is actually nothing at the Gate array that could indicate some special handling of the other banks. You have RAMEN and RAMENX, each one activating one SRAM chip. Maybe there was an early idea of this bigger SRAM area, still shown in the manuals, but later, only the well-known EC-EF, and as expansion, E8-EB remained.

 

And the test program should be correct, you can use a stop watch to verify it. The 1-wait state access runs exactly one second longer than the 0-wait state access. Or you add some more loop iterations to make it clearer.

I agree. I do not recall the reasons behind labeling the entire 384K as FAST ram, however, as you point out, there is no hardware nor software proof to continue treating >C0 to >E7 as FAST pages.

 

Interestingly, there is also a memory initialization routine in the OS that looks for memory at page >40 (64) and if RAM is found, the entire range from >00 to >7F is treated as FAST.  Is there any reason to retain this code and any internal configuration affected by the value in MEMFLG?

 

MEGFLG DATA 0            0 for 512k on system board, >ffff for 1024k (ie:fast)

PAG512 BYTE 64

* time to check for 1 megabyte of memory
* all pages will be mapped at >C000 when we check them
*
* if we have a megabyte of fast memory, the fast pages will be allocated
* before slow pages which may be in the expansion card
*
       CLR  @MEGFLG           assume 512k to start with
       MOVB @PAG512,@MAPPER+6 put it at >C000
       INV  @>C000            we have to invert in twice to leave same
       MOV  @>C000,R0
       INV  R0
       INV  @>C000
       C    @>C000,R0         pretty good check for vacant page
       JNE  NOTMEG            not equal means no memory there
       SETO @MEGFLG           we have 1 meg of memory on the CPU card

 

As a side note, I changed your program to use a MOV instruction and the results were consistent:  110 for pages E8 and EC,  130 for all other pages.

[+9640News]

I don't have a Memex in my system at the moment ? but I think page >40 has the potential to be zero wait state.  I don't think there was any way to determine if it was 0 or 1 wait state on a Genmod system.  That would not necessarily mean that >00 to >3F would be zero wait state, but it has the potential as it is an indication of a Genmod'ed system.

 

Beery

[+InsaneMultitasker]

Well, it turns out that I have been inadvertently looking at an older version of the memory XOP source code and need to update my research folder!   

 

When I inspected the code on my Geneve, I discovered the >C0 - >E7 memory pages have been allocated as "SLOW" RAM since March 2021 (and present in the MDOS 7.30 release). I even made a comment about @mizapf's tests.  We covered this ground already and I forgot all about it!  Sorry about that.

 

MEGFLG and the "1 meg memory option" code is still an open question.   I suppose the Genmod Memex would trigger the OS to declare pages >00->E7 pages as FAST but with everything running at the same speed, there wouldn't be much benefit, at least nothing that comes to my mind? 

 

[+InsaneMultitasker]

The following program PLAYE is derived from the GPL 6.50/7.00 codebase. I updated it to pass the v9938 mode bit for 80 column mode support.  I have plans to merge future GPL/EXEC changes, including command line speed/rompage selections, though for now its release is intended only to provide a means for Geneve users to run the 80 column Adventure cartridge.  

 

PLAYE-tifiles.zip

[+InsaneMultitasker]

Yesterday, I encountered a situation where the last block of a program file was not being copied from the source to the destination.  Within the Geneve OS's DSR, if a calling program attempts to access a block beyond the end of the file (using direct input/output BREAD/BWRITE), an error is generated and the DSR returns the number of sectors that were not read.  Very few programs make use of this specific error functionality. 

 

The OS's TIPI DSR routine appears to incorrectly increment the sector count when this error is encountered.  Unfortunately, the Geneve OS's COPY command uses this feature.  It is therefore strongly recommended that you use Directory Manager or GDM2K or XCOPY, whenever copying files to/from the TIPI* devices, until further notice.

 

A possible solution has been identified but the change affects other areas of the TIPI DSR.  Further testing and bug confirmation is planned for later this week.

 

CLARIFICATION: This issue is within the Geneve OS/MDOS TIPI routines, not the TIPI card nor the TIPI DSR EPROM.  An updated MDOS release is required to fix this problem.

[Nick99]

On 3/15/2021 at 6:02 PM, 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

 

@9640News this is the open source for JPEG written in C, maybe someone can use it to make the Geneve or TI with 80-column cards process the JPG format.

https://github.com/uclouvain/openjpeg/releases/tag/v2.4.0

 

[+9640News]

4 hours ago, Nick99 said:

@9640News this is the open source for JPEG written in C, maybe someone can use it to make the Geneve or TI with 80-column cards process the JPG format.

https://github.com/uclouvain/openjpeg/releases/tag/v2.4.0

 

Thanks for that link.  I just looked at some of the source briefly, and it is way over my head.  If someone can take it to 9900/9995 assembler code, that would be great if even for the simplest of jpeg files.

 

Beery

[+mizapf]

I think JPEG makes use of quite a bunch of mathematics, discrete cosine transform for instance. This could be a bit above the weight class of our machines, at least for full-screen pictures.

[Willsy]

2 hours ago, mizapf said:

I think JPEG makes use of quite a bunch of mathematics, discrete cosine transform for instance. This could be a bit above the weight class of our machines, at least for full-screen pictures.

It was quite an ask even for accelerated Amigas (Amiga 4000 etc.) back in the day - so I imagine a 9995 would really struggle.

[+OLD CS1]

48 minutes ago, Willsy said:

It was quite an ask even for accelerated Amigas (Amiga 4000 etc.) back in the day - so I imagine a 9995 would really struggle.

Unaccelerated, too!  I was viewing JPGs on my stock Amiga 500 during my IRC days.  It took some time to decode, but it worked.  Granted, we are talking a 32-bit CPU at 7MHz.

[+FarmerPotato]

Another goal would be a PNG decoder. The heart of that would be an implementation of Zlib compression. I’ve seen plain C versions of Zlib, but estimated the effort as very high for writing optimized assembly.

 

Just the decoding half would cut down the effort. but I haven’t seriously looked at it. 
 

Zlib contains the Deflate algorithm used in Zip files. Killing two birds with one stone…

 

 

 

 

[+OLD CS1]

The way I figure it, if the Commodore 64 can decode JPEG on a 1MHz 6502, we (well, someone,) can do it on a 12MHz TMS-9995 Geneve, and probably with fewer tricks than are required on the C64.

[GDMike]

19 hours ago, 9640News said:

Thanks for that link.  

I wonder if sending a request for jpeg conversion via tipi network and receiving the file back from a processor would work.

[Tursi]

14 minutes ago, GDMike said:

I wonder if sending a request for jpeg conversion via tipi network and receiving the file back from a processor would work.

It'd probably be faster.

 

[+OLD CS1]

5 hours ago, GDMike said:

I wonder if sending a request for jpeg conversion via tipi network and receiving the file back from a processor would work.

 

4 hours ago, Tursi said:

It'd probably be faster.

Yeah, but where is the fun and challenge in that??  Asking for the guy who is actually going to take up the fun and challenge of a native Geneve JPEG decoder.

[GDMike]

3 hours ago, OLD CS1 said:

 

Yeah, but where is the fun and challenge in that??  Asking for the guy who is actually going to take up the fun and challenge of a native Geneve JPEG decoder.

Well that's not the Google way of thinking, you must be destroyed!

[Nick99]

@9640News on the attached disk-image are two files called GIFSPECS1 and GIFSPECS2, it's not any source code for a GIF-loader, but maybe it can be helpful anyway.

 

pc06-05 021101 1020.dsk

[+InsaneMultitasker]

Noting a few items that have come up in other threads:

1) Review path.file length limitations imposed by the hard drive device standard and whether it is feasible and possible to extend the Geneve DSR to allow for >>40 characters.  Barriers:  DSR buffers, parse XOP, load task XOP, and majority of programs that check/adhere to the limit.

2) Review new, faster memory wait state test routine.  Is there any benefit to using it in the Geneve OS memory page detection powerup, so that fast and slow task page linked lists correspond to the actual speeds versus as-defined?

3) Can SCSI/IDE/RamHD buffer page be relocated programmatically from SRAM page >E8 to a DRAM page, to allow systems without the 32K SRAM expansion to run Geneve OS?

[+9640News]

2 hours ago, InsaneMultitasker said:

Noting a few items that have come up in other threads:

1) Review path.file length limitations imposed by the hard drive device standard and whether it is feasible and possible to extend the Geneve DSR to allow for >>40 characters.  Barriers:  DSR buffers, parse XOP, load task XOP, and majority of programs that check/adhere to the limit.

2) Review new, faster memory wait state test routine.  Is there any benefit to using it in the Geneve OS memory page detection powerup, so that fast and slow task page linked lists correspond to the actual speeds versus as-defined?

3) Can SCSI/IDE/RamHD buffer page be relocated programmatically from SRAM page >E8 to a DRAM page, to allow systems without the 32K SRAM expansion to run Geneve OS?

On #2, I am seeing with MAME and the MEMEX switches, we have the potential we may not be identifying fast/slow pages correctly on bootup.  If on the switchbox TIMODE is OFF (lack of page >3A??), then while we may recognize we have a MEMEX, the Turbo switch could be fast or slow unless the real hardware defaults to fast regardless.  I'm not 100% sure of that setting.  I am going to add another post after this one to have someone do some testing with @mizapf latest program.

 

Beery

 

[+9640News]

@arcadeshopper 

 

If you have the time, can you run @mizapf's program below on you GenMod system in both TIMODE ON/OFF and TURBO ON/OFF and take a photo of each screen?

 

Want to confirm things.

 

Beery

 

WAITST