DivMMC in the development version

This section is for discussing everything about Next hardware and latest updates.
Alcoholics Anonymous
Posts: 775
Joined: Mon May 29, 2017 7:00 pm

Re: DivMMC in the development version

Postby Alcoholics Anonymous » Tue Mar 23, 2021 7:10 pm

If you want to go a little further, the Pentagon personality will properly display Pentagon programs. You can also turn the Pentagon into a Pentagon 512K or Pentagon 1024K for which there are a few programs and demos. There is a cat movie for P512 and the recent sid emulator for turbosound and P1024.

Nextreg 0x8f controls the memory mapping mode ( https://gitlab.com/SpectrumNext/ZX_Spec ... g.txt#L854 ) and you can set it to Pentagon 1024K (you will only get 768K if there is only 1MB sram). You have to remember to enable port 0xeff7 in the internal port decodes nextreg 0x85 ( https://gitlab.com/SpectrumNext/ZX_Spec ... g.txt#L795 ).

You can do this from basic:

OUT 9275,143: OUT 9531,3: REM Pentagon 1024K memory mapping
OUT 9275,133: OUT 9531,4: REM Enable port 0xeff7

After this Pentagon 512K and Pentagon 1024K programs should work.

For the Pentagon you may also want to make sure the dacs are enabled (I can't remember how that is controlled via the boot) in the internal decodes as some programs are using dacs. And there's the F8 function key to speed up the cpu. A few pentagon programs are written for "turbo mode" which means 7MHz in Russia.

There is a new bug in esxdos 0.8.8 that prevents it from launching Kpacku Deluxe from the nmi menu. That's the only one I have noticed so far but surely there must be others. Instead that demo needs to be launched from basic. Do that like this:

.vdisk 0 : REM unmount trd in drive 0
.vdisk 0 kpacku~1.trd : REM mount trd in drive 0
RANDOMIZE USR 15616 : enter TRDOS menu (I hope I have that right)
LIST : REM see files
RUN "boot" : REM or whatever basic load if boot is not there

To add a multiface, add the name of the rom after the esxmmc.bin file in the menu line. The roms must be stored in machines/next and the names are important as that will determine which version of the multiface hardware is set. I can't recall the names offhand but you can find them in the tbblue.fw file easily if you run ".strings tbblue.fw" from the root directory. (There will be a weird error if you break out of .strings -- that's the known issue mentioned previously). Our .strings is present in /dot and is for nextzxos so you may want to run it before switching to pentagon personality. esxdos may have a strings also and it will be in /bin if there is one.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: DivMMC in the development version

Postby slingshot » Tue Mar 23, 2021 7:37 pm

Yeah, something must be changed. I've tried to locate what's relevant in the git history, but there are lot of things in it.

Alcoholics Anonymous
Posts: 775
Joined: Mon May 29, 2017 7:00 pm

Re: DivMMC in the development version

Postby Alcoholics Anonymous » Tue Mar 23, 2021 9:01 pm

slingshot wrote:
Tue Mar 23, 2021 7:37 pm
Yeah, something must be changed. I've tried to locate what's relevant in the git history, but there are lot of things in it.
I don't think it's an incompatibility that may have been introduced, more likely additional or different initialization is needed.

In 3.01.10 we got rid of the hard reset (this now results in the fpga reloading the core), among other things, and that's an important change in terms of the fw boot code. The reason for that was we need to reclaim the 8K of boot code that was allocated in fpga bram in order to allow a new hdmi implementation to have 8K of line buffer. We haven't actually removed the 8K buffer yet and plan to replace it with an initialized bank 7 containing the boot code on power up. I don't know how you are handling the hard reset now.

In the Mister adaptation, most of the keyboard input is retained including the membrane module which is now needed for the keyboard joystick. We did change the ps2 to go through the membrane module as well because the membrane module is handling the extended keys (the new keys on the zx next keyboard). Because of that we've gotten rid of the F1-F10 function keys but the mister project added them back into the ps2 module and eliminated the emu_fnkeys.vhd that we are now using for the ps2 keyboard. In 3.01.10 on Next hw, the ps2 is behaving like the membrane keyboard in that you have to press the nmi button (F11) and then a number key 1-0 to generate the function key. Another reason for doing this is we are likely going to be adding and/or changing the function keys so that, eg, signals can be sent to the pi zero. One purpose for this is to control the tzx loader in the pi.

I should have mentioned the ps2 has a us keyboard mapping loaded in the nextzxos you downloaded where ESC=break, `~ = EDIT, TAB = TRUE VIDEO, \ = INV VIDEO, CTRL = sym shift, LEFT ALT = EXTEND, RIGHT ALT = GRAPHICS, BACKSPACE = DELETE and PAUSE/BREAK = reset the ps2 module.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: DivMMC in the development version

Postby slingshot » Tue Mar 23, 2021 10:14 pm

I didn't connect the PS2, but only (an external) membrane matrix (connected to o_KBD_ROW and i_KBD_COL). Now you answered why the Sinclair joystick doesn't work. However how is it supposed to work in a real Speccy case, when you only connect the flat cables? Or the toplevel should mix the joystick input with the membrane input? Then why the two joystick input signals? Only for Kempston + MD?

As the MiST is also full with the BRAM, I hope no more boot code will put there. I didn't handle the reset differently, there's a hard reset button on the board, one should press it to reload the core. F1 and F4 works identically.

(+I've used the slower but bigger SDRAM to store TZX files, which can be played back to the core via my tzxplayer.vhd module. It's here, if you're interested: https://github.com/gyurco/ZX_Spectrum-1 ... player.vhd).

Alcoholics Anonymous
Posts: 775
Joined: Mon May 29, 2017 7:00 pm

Re: DivMMC in the development version

Postby Alcoholics Anonymous » Tue Mar 23, 2021 11:03 pm

slingshot wrote:
Tue Mar 23, 2021 10:14 pm
I didn't connect the PS2, but only (an external) membrane matrix (connected to o_KBD_ROW and i_KBD_COL). Now you answered why the Sinclair joystick doesn't work. However how is it supposed to work in a real Speccy case, when you only connect the flat cables? Or the toplevel should mix the joystick input with the membrane input? Then why the two joystick input signals? Only for Kempston + MD?
On an original spectrum, an external interface can pull D4-D0 low when port 0xfe is read to add more key input to the membrane reading. This is how external keyboards and the if2 (with sinclair sticks) is working.

In the Next we don't have the membrane directly on the z80 bus. It's not actually possible to do so because the Next can run at higher speeds up to 28MHz and the io cycle is too short to get reliable reads from the physical membrane if it is directly connected to the z80 bus as it is on the original. So instead the fpga is continuously scanning the membrane at a controlled speed and keeping an internal representation of the 8x5 (actually 8x7 for the Next) matrix. When the z80 wants to read port 0xfe, this internal representation is used during the io cycle.

The way the Next is now doing things, the ps2 and keyboard joystick is mixing their information into the membrane scan directly. See https://gitlab.com/SpectrumNext/ZX_Spec ... .vhd#L1699 where the column data read from the membrane has the ps2 and keyboard joystick mixed in. In other words, the ps2 module is keeping an internal representation of the 8x7 matrix and is supplying raw membrane data to the membrane module depending on what row is currently scanned. The keyboard joystick is doing the same. So all key input passes through the membrane.vhd module which serves all port 0xfe reads.

The function keys are managed through the emu_fnkeys.vhd module ( https://gitlab.com/SpectrumNext/ZX_Spec ... .vhd#L1644 ). The z80 top 8 bits of the io address for port 0xfe is passed through this module in "zxn_key_row" and this module filters the row to generate "key_row_filtered" to read row(s) from the membrane module. The result from the membrane module comes in as "membrane_col" and the module again filters that to produce "zxn_key_col" which is the result read by the z80. The filtering is done to do function keys. If the nmi button is pressed, the rows are filtered so that the function key rows only are scanned by an internal state machine looking for function keys and reads by the z80 are ignored. The columns are filtered so that the z80 reads no key press while function keys might be presseed. So it is this module that does the function keys and has been eliminated by the mister adaptation in favour of directly scanning the ps2 F1-F12. It should really be behaving like Next hw though.

The Siinclair and Cursor sticks are read in the membrane_stick.vhd module ( https://gitlab.com/SpectrumNext/ZX_Spec ... .vhd#L1703 and https://gitlab.com/SpectrumNext/ZX_Spec ... k.vhd#L172 ) and it is the memory pointed at by the last link that holds data to read the sinclair and cursor sticks. All that is required are the two 11-bit md pad vectors representing the two joystick results as input for the joysticks to work. This module does the 11-button md pad to keys mapping and it also applies key mappings for buttons beyond the directions and single fire button if those are defined when sinclair, cursor or kempston is selected. That way the additional buttons on an md pad can be mapped to keys even for sinclair, cursor, kempston. md pad maps XYZ to keys as well.

The two joystick connectors are read using the sega algorithm which works for atari sticks and md pads ( https://gitlab.com/SpectrumNext/ZX_Spec ... tor_x2.vhd ). The 11-bit joystick vectors come out of this and this is what can be replaced on other boards. The Next is using the joystick connectors for more than just joysticks though -- it is also using the connectors as bit-banged interface and uart among other things. This is the io mode mentioned in the module.
As the MiST is also full with the BRAM, I hope no more boot code will put there. I didn't handle the reset differently, there's a hard reset button on the board, one should press it to reload the core. F1 and F4 works identically.
This will reduce bram use by 8K and reuse the existing bank7 8K for boot rom. I guess the mist does not have hdmi so as we're going to use the freed 8K for hdmi line buffer, this will remain free on the mist?
(+I've used the slower but bigger SDRAM to store TZX files, which can be played back to the core via my tzxplayer.vhd module. It's here, if you're interested: https://github.com/gyurco/ZX_Spectrum-1 ... player.vhd).
Thanks for that. I have seen it before -- does it handle most tzx files? We're currently using a tzxplayer on the pi that will send audio through the tape bit to load as a normal tape deck would. The signal can also be saved to physical tape deck through the MIC. One thing we can do is get the pi to play back at 2x, 4x, 8x speed and the Next will load at higher speeds if the cpu is set to 7, 14, 28MHz. I supposed the same could be done by modifying that module. I am staying away from an additional tzx module for now as we have a lot of things still in the todo that demand space and the pi solution we have is pretty good, at least once we put in the controls to stop, start, rewind, etc.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: DivMMC in the development version

Postby slingshot » Wed Mar 24, 2021 9:40 am

Ok, so I have to mix the joystick (if it's Sinclair or Cursor) into the keyboard matrix before I feed to zxnext.vhd. My first impression was that it's done internally.

Yeah, no HDMI, so the (big) line buffer is not used. However there's still a linebuffer for the scandoubler, just not 8k (~3-4k).

The TZXPlayer eats almost everything, there are some block types, which are not handled (like jumps and calls), because the TZX is streamed. However stop and loops are processed. Controls are otherwise limited (it's possible to play/pause or fully rewind). It plays back protections very nicely (even on CPC). Also it can keep the pace with the turbo modes. But I've encountered some TZX-es, which works well with the pure ZX core, and broken in the Next (hangs after load, or crashes). Maybe original protected loaders are more creative with undocumented instructions/flags use or they hit the extended opcodes. (I'm progressing with the port of the flags/memptr to T80n, I'll rework the address bus fix patch to not introduce a combinatorial logic on the A output).

Alcoholics Anonymous
Posts: 775
Joined: Mon May 29, 2017 7:00 pm

Re: DivMMC in the development version

Postby Alcoholics Anonymous » Wed Mar 24, 2021 2:15 pm

slingshot wrote:
Wed Mar 24, 2021 9:40 am
Ok, so I have to mix the joystick (if it's Sinclair or Cursor) into the keyboard matrix before I feed to zxnext.vhd. My first impression was that it's done internally.
You can do it the same way as done in the Next reusing the same modules. There are three places where external input can enter: the column data if there is a membrane, the ps2 codes in the ps2_kbd module -- the mister implementation uses this, and the 11-bit vectors for two joysticks that indicate buttons and directions. All the joysticks will work if the appropriate bits indicating buttons and directions are set.
The TZXPlayer eats almost everything, there are some block types, which are not handled (like jumps and calls), because the TZX is streamed. However stop and loops are processed. Controls are otherwise limited (it's possible to play/pause or fully rewind). It plays back protections very nicely (even on CPC). Also it can keep the pace with the turbo modes.
Good to know.
But I've encountered some TZX-es, which works well with the pure ZX core, and broken in the Next (hangs after load, or crashes). Maybe original protected loaders are more creative with undocumented instructions/flags use or they hit the extended opcodes. (I'm progressing with the port of the flags/memptr to T80n, I'll rework the address bus fix patch to not introduce a combinatorial logic on the A output).
Can you give some examples of failures? These programs do need to be loaded using the correct options (128k, 48k, usr 0, pentagon, etc) otherwise the machine may not be configuring for the appropriate model. New users (not you) quite often experience a lot of user error... you will see in videos they go to load up Castlevania, the tap menu comes up to select configuration and they decide on a Next load which is the wrong thing to do; you will get Next roms, Next timing (+3 without contention), all the peripherals enabled. Castlevania will work under that circumstance but some set of programs will not. Games like Aquaplane you have to know will only work properly on a 48K spectrum so it has to be loaded as a 48K. Even if you know these things, you still have to know about the loading interface.

We only have two known programs that do not run properly besides the testers looking at memptr, flags, etc. You also have to test with the new nextzxos you grabbed as we switched away from using roms with light patches to using unaltered roms for legacy loading. There is no amount of patching, even a single byte, that won't disturb something.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: DivMMC in the development version

Postby slingshot » Wed Mar 24, 2021 4:36 pm

Alcoholics Anonymous wrote:
Wed Mar 24, 2021 2:15 pm
You can do it the same way as done in the Next reusing the same modules. There are three places where external input can enter: the column data if there is a membrane, the ps2 codes in the ps2_kbd module -- the mister implementation uses this, and the 11-bit vectors for two joysticks that indicate buttons and directions. All the joysticks will work if the appropriate bits indicating buttons and directions are set.
I think it's a bit overkill for my purposes, e.g. I don't need special sampling and such, and as I see, it uses some BRAM, too. Injecting the joystick to the keyboard is just a one-liner (or two for cursor).
Can you give some examples of failures? These programs do need to be loaded using the correct options (128k, 48k, usr 0, pentagon, etc) otherwise the machine may not be configuring for the appropriate model. New users (not you) quite often experience a lot of user error... you will see in videos they go to load up Castlevania, the tap menu comes up to select configuration and they decide on a Next load which is the wrong thing to do; you will get Next roms, Next timing (+3 without contention), all the peripherals enabled. Castlevania will work under that circumstance but some set of programs will not. Games like Aquaplane you have to know will only work properly on a 48K spectrum so it has to be loaded as a 48K. Even if you know these things, you still have to know about the loading interface.

We only have two known programs that do not run properly besides the testers looking at memptr, flags, etc. You also have to test with the new nextzxos you grabbed as we switched away from using roms with light patches to using unaltered roms for legacy loading. There is no amount of patching, even a single byte, that won't disturb something.
I've attached The Train (again), it just freezes after load (black screen - maybe another Next instruction hit?). It's loaded in 48k personality. I'm curious if they work with the RPi based TXZ loading. It works well on the pure ZX core (with the same tzxplayer module).

I'm finished with porting the patches to T80n:
https://gitlab.com/gyurco/ZX_Spectrum_N ... a4eca53c77
https://gitlab.com/gyurco/ZX_Spectrum_N ... 1a52dc3437
https://gitlab.com/gyurco/ZX_Spectrum_N ... a7e54e37c7

The first two was Sorgelig's work, the last one is mine. A minor increase of the size of T80n happened, you will decide if it's acceptable or not. To have a fully passing Timing_Tests-48k, some contention fixes in the ULA has to be done.
Attachments
tzxtrain.zip
(31.65 KiB) Downloaded 58 times

Alcoholics Anonymous
Posts: 775
Joined: Mon May 29, 2017 7:00 pm

Re: DivMMC in the development version

Postby Alcoholics Anonymous » Wed Mar 24, 2021 6:35 pm

slingshot wrote:
Wed Mar 24, 2021 4:36 pm
I think it's a bit overkill for my purposes, e.g. I don't need special sampling and such, and as I see, it uses some BRAM, too. Injecting the joystick to the keyboard is just a one-liner (or two for cursor).
Ok fair enough. There is no bram involved -- it is a small amount of distributed ram (64 x 6 bits) implemented in LUTs. I don't know the Altera architecture but it should have something like that. The user defined keys joystick will be a thing however and it is implemented through that module.
I've attached The Train (again), it just freezes after load (black screen - maybe another Next instruction hit?). It's loaded in 48k personality. I'm curious if they work with the RPi based TXZ loading. It works well on the pure ZX core (with the same tzxplayer module).
It loads fine here. I think the issue is probably how the machine is configured before loading starts. The tzxload and tapload are done with programs that configure the machine before loading; these programs are largely in basic and can be found in the nextzxos directory. Some of the things they do include putting the legacy roms in place, change video timing and disable peripherals which could conflict with software. The tzx loader expects a pi to be there as it communicates with the pi to start the audio signal.

There is no ready made way to do this otherwise but you may be able to get a similar setup by trying to start an if2 cartridge from the nextzxos->more menu. If a 48K rom cartridge is selected then a 48K machine will be set up and similar for the 128K rom cartridge. These will turn on the expansion bus and reset. Without if2 carts attached you'll just start up in basic with the original roms in place. So I think you can do a better tzx load test by choosing the 48K rom cartridge and LOAD "" to read the audio signal.

EDIT: Aha, Garry put in the machine options for the built in tape loader from the nextzxos menu. more->tape loader. I haven't paid attention to audio loading for a long time so I'm not sure when he did that.
I'm finished with porting the patches to T80n:
https://gitlab.com/gyurco/ZX_Spectrum_N ... a4eca53c77
https://gitlab.com/gyurco/ZX_Spectrum_N ... 1a52dc3437
https://gitlab.com/gyurco/ZX_Spectrum_N ... a7e54e37c7

The first two was Sorgelig's work, the last one is mine. A minor increase of the size of T80n happened, you will decide if it's acceptable or not. To have a fully passing Timing_Tests-48k, some contention fixes in the ULA has to be done.
Thanks. It will take a little while to try these things as I am in the middle of testing the 2D boards.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: DivMMC in the development version

Postby slingshot » Wed Mar 24, 2021 8:00 pm

Alcoholics Anonymous wrote:
Wed Mar 24, 2021 6:35 pm
slingshot wrote:
Wed Mar 24, 2021 4:36 pm
I think it's a bit overkill for my purposes, e.g. I don't need special sampling and such, and as I see, it uses some BRAM, too. Injecting the joystick to the keyboard is just a one-liner (or two for cursor).
Ok fair enough. There is no bram involved -- it is a small amount of distributed ram (64 x 6 bits) implemented in LUTs. I don't know the Altera architecture but it should have something like that. The user defined keys joystick will be a thing however and it is implemented through that module.
When it'll done, I'll consider using the module. However it still uses a Xilinx specific module, isn't it considered to use generic ones? Not just here, but at other places, too.
There is no ready made way to do this otherwise but you may be able to get a similar setup by trying to start an if2 cartridge from the nextzxos->more menu. If a 48K rom cartridge is selected then a 48K machine will be set up and similar for the 128K rom cartridge. These will turn on the expansion bus and reset. Without if2 carts attached you'll just start up in basic with the original roms in place. So I think you can do a better tzx load test by choosing the 48K rom cartridge and LOAD "" to read the audio signal.

EDIT: Aha, Garry put in the machine options for the built in tape loader from the nextzxos menu. more->tape loader. I haven't paid attention to audio loading for a long time so I'm not sure when he did that.
Seems I have no luck, it doesn't load even from external EAR socket. I skip this...

Thanks. It will take a little while to try these things as I am in the middle of testing the 2D boards.
No problem, they won't go anywhere.


Who is online

Users browsing this forum: No registered users and 10 guests