Is it a sparkling effect on random pixels that you see? I had this problem with a pi zero connected to my benq computer monitor. I fixed it by using a very thick gauge HDMI cable. The cheap thin HDMI cable was really bad. A medium gauge cable was improved but still sparkled. Then I used one of the really thick cables that doesn't bend well and the pi zero looks perfect with that. I can't find the model or brand name of it right now.
Thanks for the hint. I gave it a try and purchased another DVI-HDMI cable.
This time I went to the computer shop and asked for a cable to connect a computer to the 4K TV.
And the weird pixels are gone So I'm a little bit dissapointed about the "Amazon Basics" cable quality, which was not good enough for 4K ...
The file contains the source code of the modified defaultplugin, the plugin as a binary and the complete U1MB rom (512kB) with the updated plugin. Everything based on the version 1.25 of the U1MB firmware.
It would be great if you could merge it into the upcoming 2.00 delivery
I understood that the plugin binary compatibility between the versions 1.25 and 2.00 of the U1MB firmware will be broken.
Unfortunately Jon was continuously updating the documentation on his web page, so the current version does not match the (still official) 1.25 release anymore. The 2.00RC firmware distributed to volontiers was only a binary.
I understand that version 2.00 will be released soon (together with updated docs and example plugin source code).
Until then the only way to play around with plugin development is to use version 1.25.
And so I did:
I have modified the HardwareSetup section:
compiled it and tested in Altirra only (since I already have the 2.00RC in my real U1MB).
It works as supposed. On every reset the memory bank containing a menu on the multicarts: Atarimax 1mb / 8mb, SIC, etc. is selected.
Since those carts do not have a reset button, you would need to power off the Atari to start a new game.
Now you just press RESET and voila the cart menu is displayed
In the next setp I wanted to make it configurable: to enable/disable this feature over U1MB menu.
I looked at the source code and I'm confused:
@ dta Item (1,CovoxToggle,Title,ItemType.OnOff,StereoPokey,Help,Cfg.Aux,$01)
.byte 'Stereo Pokey',0
.byte 'Enable/disable stereo audio',0
@ dta Item (1,Device3Toggle,Title,ItemType.OnOff,CovoxFlag,Help,Cfg.Aux,$02)
.byte 'Enable/disable Covox',0
Menu item for Stereo uses CovoxToggle and menu item for Covox uses Device3Toggle ?
I'd strongly recommend testing Plugins in Altirra before committing them to real hardware (since a bad plugin can completely brick the system).
And how to set the U1MB emulation in Altirra up?
I have selected "Ultimate1MB" in the "Memory Config" (menu System).
Then Altirra shows:
"Altirra Ultimate1MB recovery BIOS
Insert BIOS flash disk, press key"
Which disk do I need?
I got the solution in the Altirra Help:
"Altirra does not come with the U1MB firmware, which must be obtained separately. However, it does contain a recovery image with a minimal BIOS and OS that can be used to run the flasher disk to load the real hardware. Alternatively, if the image is available in raw image form it can be bound directly through the System | Firmware | ROM images menu item."
It tells about the following single and double sided disk formats:
SS/SD (90K, 128 bytes per sector, 720 sectors, 18 sectors per track, 40 tracks)
SS/ED (130K, 128 bytes per sector, 1040 sectors, 26 sectors per track, 40 tracks)
SS/DD (180K, 256 bytes per sector, 720 sectors, 18 sectors per track, 40 tracks)
SS/QD (360K, 256 bytes per sector, 1440 sectors, 18 sectors per track, 80 tracks)
SS/DD 512 (180K, 512 bytes per sector, 360 sectors, 9 sectors per track, 40 tracks)
(360K, 512 bytes per sector, 720 sectors, 9 sectors per track, 80 tracks)
SS/HD (720K, 256 bytes per sector, 2880 sectors, 36 sectors per track, 80 tracks)
DS/DD (360K, 256 bytes per sector, 1440 sectors, 18 sectors per track, 40 tracks per side)
DS/QD (720K, 256 bytes per sector, 2880 sectors, 18 sectors per track, 80 tracks per side)
DS/DD 512 (360K, 512 bytes per sector, 360 sectors, 9 sectors per track, 40 tracks per side)
(720K, 512 bytes per sector, 720 sectors, 9 sectors per track, 80 tracks per side)
DS/HD (1440K, 256 bytes per sector, 2880 sectors, 36 sectors per track, 80 tracks per side)
All those formats are related to the Atari 8-bit computers and all were supported by existing floppy drives.
OK. Some of them were exotic, like TOMS, Karin, etc.
If you only know the disk size and the number of bytes per sector (from ATR header),
you can't (for example) say if it is a "DS/DD" or a "SS/QD" disk (both support 360K and have 256 bytes per sector).
The ATR header does not simply allow for a unique identification.
At the end it is only a name, but I agree that the naming shall be at least consistent across RespeQt.
I have built (only for Windows) a RespeQt version that identifies (additionally to SD/ED/DD):
- 360K disks as DS/DD
- 720K disks as DS/QD (naming from Atariki and sio2bsd)
The writing of a "hard disk" name is also corrected.
This version is built on top of the development branch and contains all features developed since r4 release.