@sludge:
1)
Mouse: The Next only uses ps/2 mice that plug into the ps/2 socket. These are converted to Kempston protocol in the FPGA core. It's purely a hardware thing, there's no software drivers or USB stack. You're thinking of some mice that were made 20-25 years ago that could speak both USB and ps/2 protocol, and had a USB plug with an adaptor. The adaptor just passively passes through the four USB pins to the four ps/2 pins, with some resistors so that the mouse could detect when to switch to ps/2 protocol instead of USB protocol. Almost no modern USB mice speak ps/2 protocol, so just ramming an adaptor on one of these does nothing. There are plenty of modern ps/2-only mice available though, as well as second-hand dual USB/ps2 mice. The USB port on the Pi is for... plugging USB devices into the Pi. The Next won't do anything with those unless you write special software and run it at both the Pi and Next end. The warning not to connect anything is for the PI power port, which looks like a USB socket but isn't one. The Pi does not need external powering because it's powered by the Next. Plugging in random powered stuff into this power port bypasses the Next power regulators and power management chip, which is why the warning is there.
2)
Alt cores: When the alt core authors have written them and made them available. None of them got their ks2 boards until you did, so they have only just started work on it. As soon as the first one is ready, there'll be a firmware release that enables users to load them. Until then it's disabled, because the file format of the ks1 alt cores didn't distinguish between the type of FPGA it should be run on, so you could actually brick your ks2 board by loading an old alt core intended for a ks1 board. The file format will be changed so that alt cores are safe to use everywhere.
3)
Beeper volume: No. It's mixed in hardware with a fixed algorithm. Possibly it could be changed in future. The one thing you can do is Yellow NMI >> Settings >> Sound >> BEEPer = Int. This removes the nine AY channels, four DAC channels and two I2S Pi audio channels from the beeper mix, allowing it to be mixed much hotter without the risk of clipping.
4)
HDMI colours: The HDMI output has pretty much perfect colours. I can't tell any difference between VGA, RGC and HDMI on my screen. You will see some people say they are slightly less saturated, but they are meaning by just a tiny tiny amount. What you are seeing is almost certainly some post-processing in the display. Lots of displays have game mode, cinema mode, natural lighting mode, extra sharpening, etc, that are turned on by default, and they really mess with the output from 80s micros. Turn all that stuff off, it's counterproductive.
5)
Hardware: Yes, all the hardware is available from OUTs everwhere. Everytime you see a reference to nextreg x, y, REG x, y (writing) or y = REG x (reading) you can replace this with OUT 9275, x:OUT 9531, y (writing) or OUT 9275, x:y = IN 9531 (reading). The TAP and TZX loader screens have options to disable additional hardware, for the cases where internal Next hardware conflicts with what the program is expecting (just one example: lots of games make use of floating bus to sync the screen, by reading port 255, but the built in ULA-plus feature lets you read back ULA plus data on port 255, so we give you the ability to disable ULAplus). These disabling things happen when you pick 4 (48K mode), 1 (128K mode) or P (Pentagon mode) in the loaders options. But if you pick N (Next mode) you get the full hardware enabled.
6)
48K/128K assembly code: Yes, 48K/128K assembly code works just fine. There are a few Next-specific opcodes in the ED xx range, which is the traditional expansion space Zilog themselves used for Z180, Z800, Z280, Z380, and eZ80 (and also the third party Rabbit CPU family). Unless other undocumented opcodes, which have similar functionality in the prefixed and unprefixed space, the unused opcodes in the ED space are plain nops in a regular Z80. So they are not used for pathological NOPs in regular Z80 code nearly as much as undocumented real opcodes are. Of course it is possible for somebody to deliberately release a program that uses Next opcodes, and writesit so that it breaks on a Next or a new Zilog CPU, but works on a vanilla Z80. But this is a real edge case that would be done to make a point about compatibility, and such programs could be patched if you wanted to.
7)
DAC playback: Yes, the Next has four 8bit DACs, and they can play back at any sampling rate up to about 48KHz that the player supports. You might be experiencing problems wit the tools rather than the hardware - .playwav only supports three specific formats, and hasn't been worked on for 3.5 years. Hopefully somebody will volunteer to write a more capable player. If you are talking about using PCM audio in your own programs, be aware that audacity export doesn't work that well for raw data. Maybe take a look at
SoX, which can convert to raw 8 bit samples at any sample rate.
8)
SD card tight: The SD socket on the board and the slot in the plastic case are actually fine. The problem is the Next-branded micro to full size adaptor, which is fatter than the SD association specifications describe. It's a manufacturing tolerance issue, and the samples the manufacturer gave to the Next team when the contract was signed did not have this problem. Most people are keeping their branded adaptor safe in the box, and using a Sandisk or Kingston adaptor for daily use. These are a much looser in the SD socket on the board.
9)
Joystick mapping: The joystick menu on the boot screen is in two sections:
always used and
not used by NextZXOS. The joystick settings are in this second section. The intention is that you choose the joystick setting that's right for each game you are playing in the TAP/TZX/SNA/Z80 options screen, where it will be remembered next time you play that game. Since not every game has the same requirements, it makes more sense to remember this per game than have a global default. Press J for Joystick Settings on the loader screen to see your options. The thing you are finding inconvenient to do every time is just there as an extra, to allow you to change it on the fly if you need to for a specific reason. If you find yourself needing to go into the options screen a second time, after the options have been remembered for that game, do SYM+ENTER in the browser instead of ENTER.
10)
RTC battery: It's a CR2032 lithium battery (non-rechargeable), and they just don't leak like old nicads do in Amigas etc. And they last for years, and just go dead without leaking when they die. You can of course remove it anyway, if you like. If you put something like this in your c:/nextzxOS/autoexec.bas then you would be able to set the clock on every boot, and it would be remembered until you next powered off and rerun the autoexec.bas.
Code: Select all
10 .nxtp time.nxtel.org 12300
20 ERASE
REM save with:
SAVE "c:/NextZXOS/autoexec.bas" LINE 10
Assuming you're in the UK you will get GMT or BST by default, taking summer time into account, If you are in any other zone you can ask for the time in your zone, as documented
on the wiki.