mizapf

BTW, I had issues with bgfx when I run MAME in a VM running Ubuntu (unresponsive desktop). On my real system, I always use bgfx which is also selected by auto.

Note that this is a location configured by your system. Normally, the nvram folder is a subfolder of your mame folder.

Interestingly, BSS is a widely-known concept for object code: https://en.wikipedia.org/wiki/.bss

Yes, in GPL mode (using the Editor/Assembler), or with the EXEC loader.

Sorry for the Geneve.new folder - I once started with it with the intention to sort things, but lost it out of sight... I'll have to pick it up again. I am using GeneveOS 6.50 on my real system and in MAME.

720K is what you can achieve with a DSDD 3.5" (80 track) floppy disk (2880 sectors).

If you write for native mode, you should consider TASM or GenASM, also a suitable editor. Mind that the Geneve is (should be) more than a faster TI. 🙂

There seems to be a tool JED2EQN, but I have not yet found out where to get it.

I noticed that issue when debugging the HFDC emulation in MAME. If I remember correctly, we could verify this with a real HFDC and a Lotharek/Gotek. In fact, the WD17xx and the SMC92x4 controllers just set a status bit which indicates whether it is a DAM or DDAM. It works normally in all other respects, so it seems as if the DSRs don't check the status bit. The quickest way would be to turn on the logging in MAME. I can do that in a few minutes. Do you have a particular test that I should run?

The boolean equations are the source code. For example, you have input pins i1 and i2, and output o1 = i1 AND i2. The output o1 is defined by this equation. I programmed GALs 30 years ago (created my speech synthesizer adapter board this way), and I don't remember all details. Wikipedia says that the Jedec files (.jed) contain the matrix of fuses of the PAL/GAL. A compiler produces this jedec file from the equations. It seems as if you reverse-engineered these matrices, but it should be easy to derive the equations from the matrix.

Obviously, you are missing some ROMs. I can only help you for the TI family, and in that respect, we have up-to-date ROMs for the current MAME on our WHTech server. Apart from that, a newer MAME is a better MAME.

@Fritz442Can you create equations from your JED files? I'd be really interested.

LI R5,PAB just loads R5 with the address of the first byte of the PAB. If PAB is located at address >A104, R5 will contain that value. What do you want R5 to contain? When you see LI R6,PAB+9, R6 will contain the value >A10D as a result of the addition of the location of PAB and the constant 9.

The "deleted data mark" is a special data address mark (DAM) that says that the contents of the sector shall be ignored. It is specified in the encoding of FM and MFM, but I don't know whether this is really used with any floppy drive system. However, as far as I remember, the HFDC DSR does it the wrong way, it initializes sectors with the DDAM instead of the DAM. As it is ignored by all other controller, no harm is done.

Maybe you can restrict the build to the TI family (using SOURCES=src/mame/drivers/ti99_4x.cpp etc. as arguments to make), so you'd bypass this position if it has not been fixed. What compiler do you use? (Version?)

At some time you will know how long the user input is; then you set up the PAB. A typical way is to reserve some buffer with BSS and to copy the input into the buffer. Since you have to copy the PAB into VDP memory anyway, you can also write the PAB byte 0-8 into VRAM, then wait for the user input, then append the length byte and the input bytes.

I first thought that you can provide a string to CALL DIR in the DDCC-1 (because it did not complain), but in fact it ignores invalid arguments and takes the last drive number that you used. So when you do a CALL DIR(2), all subsequent CALL DIR("DSK2"), CALL DIR("DSK1"), CALL DIR("WHAT.EVER"), CALL DIR() lists drive 2. CALL DIR of the HFDC can correctly parse a given path.

People may think about Myarc whatever they like, but the DDCC-1 is running rock-solidly here for 25 years now.

The others implement CALL INIT, LOAD, and LINK. You don't need an Editor/Assembler cartridge.

Extended Basic has SIZE, but there is no corresponding command in TI BASIC.

The DDCC-1 offers CALL FILES, CALL LLR, CALL ILR, CALL LR, and CALL DIR by its original DSR. I'm not sure how I learned about them; I got a HFDC before, and maybe I correctly assumed that they would offer the same subprograms. The HFDC manual describes all of them ("Additional commands supported by HFDC").

I mentioned that several times ("favorite controller", search the forum for CALL DIR). Edit: Try it in MAME.

@jedimatt42: What happens on the 4A when you say the screen is turned off? Does it become empty (with some color) or black? Could it be that the 9918 mistakes register 15 as register 7 (ignoring the leftmost bit) so your writing of 00 gets loaded into register 7?

One good way is to read status register 4 of the 9938. The contents look like 1111111x. The 9918 ignores any attempt to set a status register number and will return its only status register. Edit, to elaborate a bit more: The number of the status register must be set in video register 15. This register does not exist on the 9918/28, so it will ignore this setting. Also, the 9918/28 only has a single status register whose bits are [ F | S5 | C | Sn | Sn | Sn | Sn | Sn ]. F is the VSYNC, S5 is 1 if there are 5 sprites on a line, C is the collision flag, and Sn is the 5-bit sprite number of the 5th sprite. If you don't have five sprites on a line, the contents will never look like 1111111x, as does status register 4 of the 9938/9958. So once you know it is a 9938/9958, you can tell both apart using status register 2: [ FL | LP | ID | ID | ID | ID | ID | FH ]. The five ID bits are 00000 for the 9938. As far as I remember, the 9958 has ID=00010.

Use TIImageTool.