jedimatt42

The 4A side of the Geneve feels like a 4A emulator to me. Expansion card compatibility is quirky. There are newer expansion for the 4A that the Geneve can't support. Most notably, higher capacity bank switched cartridges. And then some F18A based software. Expanding RAM use is available, but different, so as we start to build on the 4A SAMS library, it also cannot work on the Geneve without being rewritten. In the retro computing hobby it cannot replace a 4A. It is simply a different beast with different strengths.

The TIPICFG reboot function peeks at the memory mapped IO state to see if it has been reset to 0 during the python startup code. Just looking for an indication that reboot finished.

I wouldn't waste any effort on support for non-compliant 4A programs, except to document that they do or do not work in maximum 4A compatibility mode.

I don't remember TIPICFG using direct messaging.

Programs that are not searching for TIPI DSR entry to find the crubase before direct messaging should go on the WALL OF SHAME which I will gladly create.

Update 1.16 - Note, I changed the names of the RPKs. FCMD.RPK is good with current MAME, and Js99er as @mizapf informed. Some folks are still on MAME 224 for reasons, so the ROM only RPK is called FCMD-MAME-224.RPK now. I changed the backspace handling. It wasn't very TI like, since we don't really have a backspace key. Now, by default, when in insert mode, left arrow is left arrow. If you set environment variable BACKSPACE=TRUE, then left arrow becomes backspace. In overwrite mode, left arrow is always left arrow. Insert and overwrite mode are toggled by pressing F2. Solid cursor is insert mode, underscore cursor is overwrite mode. Made command line entry consistent in this regard with the ED command. ALSO Hopefully I fixed the Yamaha VDP detection. It at least still works in MAME and is consistent with the 9938 documentation.

If that were 100% then my suggestion would be that ooeygui not allow navigation in the file picker.

That isn't 100% true. RPK's are left over for bespoke carts, or so I've read, and practiced, such as when I'm developing.. and fully qualified paths for RPK's work from the command line.

I find 'load config' confusing too... given there is a 'select system to load' that is a drop down list of the configs... loading a config core dumps for me. ooeygui.py: line 1067 _butloadcfg, NoneType has no attribute 'text' -- I have succeeded with download and install of mame... I probably need to read the entire manual now... Picking a cartridge fails cause it let me navigate to a different directory to find my FCMD.RPK, and then didn't pass a fully qualified pathname to mame.

Ooh... there is a PDF in the classic99 distribution, open classic99, click 'help' then 'manual' and search for FIAD, or read the whole thing, cause there is a lot of good stuff in there.

'Text' files on a 4A are not naturally compatible with modern text formats. By convention on the 4A a text file is a RECORD based file with DISPLAY type entries and a VARIABLE record length, with a typical record length limit of 80 characters. We commonly call them DV80 files. RECORD files on the 4A are more like database table store files than modern text files. For usage as source code, each record is a line. There is usually no end of line character. For usage in printing applications, the CR code is usually at the end of each record to instruct the printer to carriage return. It is archaic. On disk, a DV80 file is a linked list of records starting with a length byte that can be used to navigate to the next record. It gets more complicated... like our emulators usually store files on the host operating system in a container called TIFILES or V9T9 files, that encapsulate the metadata about record length limits, and other good stuff. You can proceed in naive mode... Classic99 has a cool feature in the DISK definition dialog that has it write DISPLAY VARIABLE files to windows text format. And another that allows opening windows text files as DISPLAY VARIABLE files. With those 2 options enabled, you should be able to use windows programming editors, and still load the source into the assembler, or even the editor on the 4A.

In post #1, the manual link is to the windows archive for version 4.0.2. The windows link is to the windows archive for version 4.0.1. Is there a manual link that is not the entire thing again for windows? Or does 'manual' mean not automated in this context?

I don't recall if this happened, but there is nothing to setup. Just join, butt-in and offer to demostrate.

There is a daemon that monitors all the stuff inside the tipi share and collects the TI filesystem meta-data so that the web-ui isn't having to open every file as it produces the page. This same daemon recognizes .DSK images and explodes them to directories matching the volume name, which creates more files... it subscribes to the filesystem change events... Anyway... If you dump a lot of files on at once, a bunch of work gets queued up. This can 'block' 4A access to the PI while it is being processed. In my experience, it settles down without issue. But, I probably never use the TIPI the same day that I've restored all the files, as this is usually only something I do when I'm done testing a fresh SD card image.

It is in post #1 part of the attached zip

Real hardware: Do you have both the FCMDG.bin and FCMDC.bin files on the FinalGROM99 SD Card? MAME: I haven't upgraded to latest MAME yet, and am using a hack to get the large ROM to work with a GROM. The GROM auto-starts, so after 'inserting the cartridge' reset the emulation. Also be sure you use the correct RPK. There are 2 in the zip, one for MAME and one for js99er.net cause they don't like custom carts the same way... EDIT: Oh.. I lied... the MAME-FCMD.RPK only has the ROM, and the hack was that I bump it up to a 512K ROM... no GROM, so no auto-start feature. I am not a regular user of MAME, so if you are, then you are the expert... here is the layout.xml I use: https://github.com/jedimatt42/fcmd/blob/master/mame-layout.xml please advise how it should be corrected. This layout.xml works for js99er but causes mame to core dump: https://github.com/jedimatt42/fcmd/blob/master/js99er-layout.xml If someone wants to tell me how to properly have one layout.xml that brings in the GROM and ROM without repacking the ROM as 512K ( it only needs to be 128K ) that would be awesome! And if the same solution worked in js99er, that would be awesome as well!

From my reading, you get the normal text mode foreground and background for tiles, and the background is shared with the screen background. The COLOR command and ANSI color setting codes control these on Yamaha chips. Then you get the second tile foreground and background in VDP_R12 for BLINKING... which... is going to blink... and everyone in the 80s rebelled. Is blinking what is desired?

That is most likely a variable speed interrupt trigger.

I found a mistake... looking at VDP status register 4 to detect the Yamaha VDPs, I'm comparing (cb) to 0xFE. However it needs to be masked first. The remaining bit is actually variable.

Great feedback! Yes, this is by design. But it doesn't have to be set in stone. F2 will toggle into overwrite mode, and backspace becomes left-arrow instead... it may merit some config options... I could see people with stock keyboards never wanting left arrow to function as backspace. And that is inconsistent with command line editing... I noticed... after getting used to the backspace being what it says on my USB keyboard... Made me want to fix command line editing to treat it like backspace also.. But then I realize that isn't very normal on a 4A.

This is basically how I fixed Acadiel's board. You can test if the CRU works, by using easy bug and setting bit 0, and seeing if the light turns on or not... If that is the case, then start with the '245. Edit, sorry, reading these posts in reverse order...

Accessing the rom depends on the '138 address decoder working, address buffers working, the databus buffer working, and the CPLD working... oh, and the ROM working.

Maybe my VDP detection code is subject to the state left behind by prior software... It pretty much just reads VDP status register 4 to decide it is a Yamaha VDP... Just before that, I use the GPU technique to identify the F18A. I've double checked the c->assembly production, and it is using byte operations, movb and cb properly... Keep an eye on it. Maybe with some more evidence, it can be improved.

Update 1.15 Readkey shows blinking cursor again... unless you pass /n to it... which I failed to document... I'll get that next time... Includes ED command now, that has built in editor. command line editing is in INSERT mode by default. It used to be in overwrite mode by default. I had a cursor crisis. The editor uses most of the upper 24k expansion for the buffer, I've set a semi-arbitrary limit of 250 lines, leaving me something like 3K of headroom for future needs in the editor before having to invoke SAMS. It scrolls over to the right on a 40 column display to support the 80 character records. It jumps to the left to the end of line when navigating up and down... This could be improved to overshoot a little and give context... Intentionally minimal features. It will not open if no filepath is specified. I'll probably fix that later, cause you can enter the filepath when you press ^S to save. Filepath given on commandline can be an aspirational filename. (the one you want to create)

Update 2.17 - fix wifi setup from TIPICFG a.k.a. CALL TIPI ( If you are setup, this offers you nothing significant ) Updated SD-Image available on my downloads site next time you need it. Updated INSTALL.md to remind me to check that wifi works when making an image. Fixed TipiSuper.py (processes certain changes to PI.CONFIG) to write the wpa_supplicant.conf to /boot/ instead of directly to /etc/wpa_supplicant/ as this allows the Raspberry PI OS to do all the other things it does when detecting that file on bootup.