MSX2+ vs Zemmix, any real difference?

Page 2/4
1 | | 3 | 4

By KdL

Paragon (1236)

KdL's picture

16-07-2019, 14:11

DarkSchneider wrote:

I am trying to use the RTCSAVE and get UNSUPPORTED KERNEL. How can it be used? No instructions.

SD generated by the sdcreate tool, and booting from SDBIOS. With the Zemmix BIOS I got a "not compatible BIOS" message so the BIOS should be fine.

RTCSAVE only work if MSX BIOS is loaded from SD card and if it has been properly modified.
The required kernel are MEGASD or MEGASDHC and does not work with NEXTOR kernel (not again).

RTC save 3.0 has been tested with OCM-SDBIOS v2.6 and OCM-PLD v3.7.1

RTC save 3.0 for One Chip MSX
Made By: NYYRIKKI 2008/KdL 2017-2019

In case someone is interested, there is a bit improved BIOS for One Chip MSX.
You can save RTC settings on SD-Card by executing 'RTCSAVE.COM'.


Installation:
- Convert an appropriate BIOS from hex-file in binary, OCM-SDBIOS Pack is suggested.
- Format your SD-Card into FAT16 and copy 'OCM-BIOS.DAT' as first file in SD-Card.
- Copy 'RTCSAVE.COM' to somewhere and run it to save the RTC settings.


Syntax: rtcsave [{/|-}option]

MAIN-ROM COLOR
--------------
Default settings without no parameter:
 if SCREEN 0  set COLOR foregr,backgr,backgr from RTC
 if SCREEN 1  set COLOR foregr,backgr,border from RTC

Custom settings through options:
 a  COLOR foregr,border,border from RTC
 b  COLOR white,black,black (15,0,0)
 c  COLOR from System Variables in RAM
 x  exclude MAIN-ROM from saving

SUB-ROM RTC CODE
----------------
Perform SET SCREEN from BASIC before saving the RTC code


Revision 3.0 (KdL 2019.05.20)
- Added MAIN-ROM color options.
- Text corrections and some additions.
- Fully revised source code.

Revision 2.2 (KdL 2017.09.18)
- Auto-scanning for RTC patch on any "custom BIOS" up to 1024 kB.
- Changed the string UNEXPECTED ERROR! into UNSUPPORTED KERNEL FOUND!

Revision 1.0 (NYYRIKKI)
- First public release.

______
Enjoy!

Example:

1 ' RTC Setup (Demo Example) by KdL 2019.05.20
2 ' for OCM-SDBIOS Pack v1.3 or later
3 '
10 SCREEN 0,2,0,1,0,0: WIDTH 80: COLOR 15,4,7: LOCATE ,,0
20 KEY ON: SET BEEP 1,3: SET TITLE "",1: SET ADJUST (0,0)
30 SET SCREEN: CALL SYSTEM("RTCSAVE^ECHO")

By DarkSchneider

Paladin (880)

DarkSchneider's picture

16-07-2019, 14:52

The BIOS is fine it already boots like a 2+ not like a Zemmix.

Where is the megasd kernel? I used the sdcreate tool and it asks for MSXDOS2.SYS and NEXTOR.SYS optionally. But have not seen the megasd or megasdhc inside file packs.

By KdL

Paragon (1236)

KdL's picture

16-07-2019, 19:51

DarkSchneider wrote:

The BIOS is fine it already boots like a 2+ not like a Zemmix.

Where is the megasd kernel? I used the sdcreate tool and it asks for MSXDOS2.SYS and NEXTOR.SYS optionally. But have not seen the megasd or megasdhc inside file packs.

The kernel can be selected during the creation of a new SDBIOS or a new SD card.
I suppose your SD card was not created properly and I suggest you do it again
running the 'new-sdcard.cmd' script located in the 'make' subfolder of OCM-SDBIOS Pack.

The result shoud be like this (in this test I used only default values):

A video that applies a new color with RTC save: SDBIOS color test

By DarkSchneider

Paladin (880)

DarkSchneider's picture

17-07-2019, 08:45

Well using the SDBIOS pack as is works. Before I created the SDBIOS by the 'make-sdb' script, then used the sdcreate from the Extra Pack, taking MSXDOS2 from one place, NEXTOR from another, etc. By this the BIOS was present (it booted like a MSX2+) but seems not to be a correct kernel version, even deleting the NEXTOR.SYS.

Generating the SDBIOS like before, but then creating the SD with the 'new-sdcard' script from the same pack, it works.

Anyway, be careful because if use Windows it has the habit to create a "System Volume Information" folder on new mounted drives, so the OCM-BIOS.DAT would not be the first file on SD. I'd had to move all the files to another drive, remove everything in the SD, deleting using command prompt (DOS) the "System Volume Information" (if you delete it from the Explorer it creates it again), and then copy the OCM-BIOS.DAT file into the SD, to be the first file.
Maybe you'd want to add this line in the script before copying the BIOS to be sure it is the first file on card:

Quote:

rmdir /s /q "System Volume Information"

This is if you do the drive change before, if not add it to the path.

By KdL

Paragon (1236)

KdL's picture

17-07-2019, 11:04

DarkSchneider wrote:

...
Maybe you'd want to add this line in the script before copying the BIOS to be sure it is the first file on card:

Quote:

rmdir /s /q "System Volume Information"

This is if you do the drive change before, if not add it to the path.

I didn't understand what you mean, it seems to me that it is already as you suggest it.

...
rd /S /Q "%dest%\System Volume Information" >nul 2>nul
if exist SDBIOS\OCM-BIOS.DAT copy SDBIOS\OCM-BIOS.DAT %dest% >nul 2>nul
if exist %dest%\OCM-BIOS.DAT attrib +R +H +S %dest%\OCM-BIOS.DAT >nul 2>nul

Whether it is present or not, the script will always try to remove the "System Volume Information" folder after re-creating the partition and before copying 'OCM-BIOS.DAT'. I suggested you use it because I knew it would work but the important thing is that the problem has been solved! Wink

By DarkSchneider

Paladin (880)

DarkSchneider's picture

17-07-2019, 11:34

I see. But I used the script and didn't boot from SDBIOS until manually removed the folder. Seems the system is insistent about creating the folder or created it between commands, as we can't ensure it is an atomic operation. So if the script already has it, maybe it could be advised in docs as some possible issue to be fixed manually by the user.

By KdL

Paragon (1236)

KdL's picture

17-07-2019, 13:13

You are currently the only user who reported the problem. In "readme.txt" of OCM-SDCREATE I specified that the tests are done with the "Administrator" account. I therefore guess that you are not using this special account (the super admin of Win10 Pro) which is the only user able to guarantee the proper functioning of the scripts because it rises above the system users. So I can't predict the most varied situations, but I can suggest to try this registry fix.

DisableRemovableDriveIndexing.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search]
"DisableRemovableDriveIndexing"=dword:00000001

In any case it has already been discussed in a thousand ways that SDBIOS must be the first file on the SD card and is not mandatory to use my scripts. Tongue

By KdL

Paragon (1236)

KdL's picture

18-07-2019, 23:08

DarkSchneider wrote:

... maybe it could be advised in docs as some possible issue to be fixed manually by the user.

I thought about your suggestion, so here are the ADVICE ON SOME POSSIBILE ISSUES. ;)

All my scripts have been tested with the super administrator of Windows 10 Pro (the 'Administrator' account) and the User Account Control (UAC) disabled. Other system configurations could create issues due to the lack of elevated privileges.

The default filename of SDBIOS is 'OCM-BIOS.DAT'. This file must necessarily be the first file on the SD-Card. If after the use of the scripts some tools like RTCSAVE do not work, it means that SDBIOS has not been saved in the right way. To solve the issue it will be necessary to remove all the contents of the SD-Card and copy 'OCM-BIOS.DAT' manually as the first file.

To solve formatting issues it will be necessary to pre-format the SD-Card manually. The primary partition can be formatted in FAT16 with a maximum of 2047 MB ​or FAT16X with a maximum of 4095 MB, so you can also use an SD-Card larger than 4 GB.

By RetroTechie

Paragon (1563)

RetroTechie's picture

18-07-2019, 22:14

DarkSchneider wrote:

(..) the OCM-BIOS.DAT file into the SD, to be the first file.

Why exactly is that? Loader uses sector reads rather than file read, or something like that?

By KdL

Paragon (1236)

KdL's picture

18-07-2019, 22:28

RetroTechie wrote:
DarkSchneider wrote:

(..) the OCM-BIOS.DAT file into the SD, to be the first file.

Why exactly is that? Loader uses sector reads rather than file read, or something like that?

IPL-ROM is a small program written in assembly that takes care of loading SDBIOS quickly, so to use as few instructions as possible it simply determines what the first file is. This software solution that was initially designed by the author Kazuhiro Tsujikawa, was maintained also in my updates because I fully agree with his choice.

Page 2/4
1 | | 3 | 4