FlashROM v5.1G

I suggest people who understand the professional software of scorpion to delve into the
GMX firmware and make some corrections that will make
the existence of users of this very GMX easier.
And for GMX users I suggest donating to the hacker for this.

So, what I would like to see in the new version:

1. Deal with the FlashROM bootloader and remove the
checksum check so that any user can make changes to the ROM
(such as flashing your ROM-DISK with your favorite programs).

2. Understand the structure of the ROM-DISK, how the program directory is organized there.

3. Fix a glitch: after formatting a floppy disk (real)
using the Disk Utility menu, very often the floppy disk becomes
one-sided, i.e. Incorrect data is entered into the service sector of the disk. In this case, the disk parameters in the Setup->Disk
Utility menu change to single-sided. This doesn't always happen, but
still...

4. Remove checking the number of the enabled screen through the variable
basic #5B5C. IMHO why such a check is needed if there
various depackers and other comrades constantly leave traces there.
As a result, the wrong screen number is constantly determined and
when working with a screw, it switches to the second screen.
The real screen is determined through port #7EFD bit 1.

5. Make a detection of the enabled extended screen (#7EFD
bit 3) when entering the shadow and enable it, if necessary,upon
exit.

6. The most important thing is to reset the #DFFD port (extended memory) to zero whenever page 8 is turned on, and restore its value at the output. This will allow you to use
additional memory, up to 2 MB, together with the hard drive.

7. Another very important change is the hard connection of disk images on the hard drive through the rst#08 functions, and not just through
monitor tools.

I think many GMX owners (if not all) will be very
happy with this version of the ROM and will gladly donate to someone who
makes it.

For those who want to delve into the firmware, I can send the firmware itself in
the form of an image disk.

[REAL ZX]

NA> Greetings to you, All!
NA>
NA> I suggest people who understand the scorpion professional software to delve into the
NA> GMX firmware and make some corrections that will make it easier
NA> for the existence of users of this very GMX.
NA> And for GMX users I suggest donating to the hacker for this.
IMHO it’s high time you wrote a new BIOS so that it works with normal
screws (with fat, different disk images...), with built-in sts, etc.
I would take it (I’m slowly writing a bios for myself), but I don’t have gmx...

J7N/4D

February 25, 2002 (and it was 1:30 pm then)
Nikolaj Amosov in his letter to All wrote:

NA> I suggest people who understand the scorpion profession to delve into the
NA> GMX firmware and make some corrections that will make it easier
NA> for the existence of users of this very GMX.
NA> And for GMX users I suggest donating to the hacker for this.

Curious, what benefits do GMX users experience from using
this very GMX? Is there a lot of software for it?

NA> 1. Deal with the FlashROM bootloader and remove the check
NA> checksums so that any user can make changes to the ROM
NA> (like flashing your ROM-DISK with your favorite programs).

This MOA protected everything with its CRC :)

NA> 2. Deal with the structure of the ROM-DISK, How is the program directory organized there
NA> Who knows. We tried to figure it out, but we still couldn’t figure it out. Apparently,
we didn’t understand it well :)

NA> 3. Fix the glitch: after formatting a floppy disk (real)
NA> using the Disk Utility menu, very often the floppy disk becomes
NA> one-sided, i.e. Incorrect data is entered into the service
NA> sector of the disk. In this case, the disk parameters in the Setup->Disk
NA> Utility menu change to single-sided. This doesn't always happen, but
NA> still...

MOA always wrote buggy software. System engineer, because...

NA>4. Remove checking the number of the enabled screen through the variable
NA> of the bass #5B5C. IMHO why such a check is needed if there
NA> various depackers and other comrades constantly leave traces there.
NA> As a result, the wrong screen number is constantly determined and
NA> when working with the screw, a switch to the second screen occurs.
NA> The real screen is determined through port #7EFD bit 1.

Hmm... A glitch in older versions of ProfROM. Everyone had been fighting for more than one year. Apparently, this very MOA has
poor feedback with users, since it
leaves glitches...

NA> 6. The most important thing is to reset
NA> the #DFFD port (extended memory) to zero at any time you turn on page 8, and restore
NA> its value at the output. This will allow you to use
NA> additional memory, up to 2 MB, together with the hard drive.

Is it not possible to use it like this? :-[]

NA> 7. Also a very important change - hard connection of
NA> disk images on the hard drive through the rst#08 functions, and not just through
NA> monitor tools.

Damn! Back in 1997, in a telephone conversation with MOA, he promised to fix this in the next version of ProfPZU (for GMX). Apparently, he neglected the users and their
problems :-:

NA> I think many GMX owners (if not all) will be very
NA> happy with this version of the ROM and will happily donate to the one who
NA> makes it.

Are there many such owners?

NA> [REAL ZX]

Vega / ex-Style Group. February 27, 2002

VK> IMHO it’s high time you wrote a new BIOS so that it works
VK> with normal
VK> screws (with fat, different disk images...), with sts
VK> built-in, etc.
VK> I would take it (I’m slowly writing a BIOS for myself), but
VK> I don’t have gmx...

Is that so? do you need GMX itself? Maybe one firmware from it is enough? Everything is there in the open.

[REAL ZX]

VS>
VS> Who knows. We tried to figure it out, but we still couldn’t figure it out.
VS> Apparently, they didn’t understand it well :)
LD wrote that he figured it out, and made his own romdisk.

J7N/4D

NA>> And I suggest that GMX users donate to the hacker for this.
VK> IMHO it’s high time you wrote a new BIOS so that it works
VK> with normal
VK> screws (with fat, different disk images...), with sts
VK> built in, etc.
VK> I would take it (I’m slowly writing a BIOS for myself) here only
VK> I don’t have gmx...

VS> Curious, what benefits do users
VS> GMX experience from using
VS> this very GMX? Is there a lot of software for it?

Personally, I’m drawn to a 2 MB RAM disk in IS-DOS. It is very convenient to pull all sorts of junk from the bbs. Ah, the advantages? It depends on what you compare it with. It’s still convenient to have Pentagon and Scorpio in one
bottle. And I have not encountered software for GMX, except dosx for
Dickie Mailer.

NA>> 2. Understand the structure of the ROM-DISK, how the
NA>> program directory is organized there.
VS>>
VS>> Who knows. We tried to figure it out, but we couldn’t

NA>
NA> Where did you write? I would really like to get acquainted...
yes, here, last summer

J7N/4D

VK>> LD wrote that he figured it out and made his own romdisk.
NA>>
NA>> Where did he write? I would really like to get acquainted...

NA> Me, M. Kondratyev, S. Zotov, M. Zharov are those I know.

Oleg Grigoriev.

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> SkyNet: 71:170/21

NA> People, someone tell me if you find it, otherwise I didn’t have it
NA>.
he actually wrote that he figured it out. If you need details, contact him directly. Or call;)

JTN/4D

DL> good people sorted it out ;)

DL>
DL> ============================================================================
DL> + Transferred by Dmitry Lomov (2:5030/675.25)
DL> + Area : REAL.SPECCY (REAL.SPECCY)
DL> + From : Vassili Klimov, 2:5054/37.28 (Mon Jul 30 2001 00:22)
DL> + To : All
DL> + Subj : CRC and ProfPZU switching in scorpion

it is not the same;). In gmx the switching, IMHO, is done differently (the structure of the flash flash seems to have been described in Spectrum Expert). People need the structure of the rom disk
i.e. in what form is the directory, files, etc.

JTN/4D

I was only talking about the fact of my own investigation, without details ;)

NA> People, someone please tell me if you find it, otherwise I didn’t have it
NA>.

Good people sorted it out ;)

=============================================================================================
* Posted by Dmitry Lomov (2:5030/675.25)
* Area : REAL.SPECCY (REAL.SPECCY)
* From : Vassili Klimov, 2:5054/37.28 (Mon Jul 30 2001 00:22)
* To : All
* Subj : CRC and ProfPZU switching in skorpe
=============================================================================
Well hello, All !

Yahoo!!!!!!!! Having spent several hours studying ProfPZU, I bring to your attention the general principle of management. So, let's start with a description: the 512kb PROM consists of 2 halves of 256kb each, in no way connected to each other and
switched by a toggle switch;). Accordingly, each of these parts completely
contains the system (according to my estimates, it takes up 70-80 kb).
Further, each part is divided into blocks of 64 kb. Switching within 16kb bank blocks is standard: if in 1FFD bit D1=1, then the monitor ROM is enabled (at any
bit D4 value 7FFD), otherwise if D4=1 (7FFD), then bass48, if D4=0, then
basic128. To enable trdos ROM you need to do
JP #3DXX.
with the bass on48. Now about switching blocks. First, the shadow area is cut in(D1=1,
1FFD). Let the block number (0-3) be specified in A, then for MOA we see the following:
ld hl,#0110:add a,l:ld l,a:jr nc,m1:inc h
m1 ld l,(hl):ld l,(hl):ret
in the line with m1 we see 2 key commands ld l,(hl)! The first one simply reads the value
from the table (there are 4 of them in total: #00, #04, #08, #0c), and the second one inserts the block.
Everything seems trivial, but it’s not clear why the table is needed? Moreover, in each of the
blocks the tables are different: the same values ​​0,4,8,c are used, but the order of their
arrangement is different! Also note that cell #0101 is used to
identify the current block. Example: they remembered the number from #0101, turned on
some block, performed some operations, used the remembered value to restore
the previous block, etc.

Now about the popular problem of calculating the CRC of the connection sector;). When
studying the source text (ZX NEWS 54), several VERY stupid
errors were identified, due to which the CRC calculation now takes a little more time,
however, only 68 bytes of memory are spent!
I won’t comment, I’m a bummer;). I just don’t recommend using this procedure for
other purposes, it’s better to write your own or take a ready-made one from the Hrust Library.

═══════════════════ newcrc .C ══════════════════

;CRC CALCULATOR ;-)
;easy generated by J7n/4D/PeRM/RuSSIA/29.07.2001
.LOCAL
;INP: HL - BUF, BC - LEN
;OUTP: DE -CRC
CRC_CALC
PUSH IX
LD IX,#FFFF
...0
LD A,(HL)
XOR LX
LD E,A
CALL ...1
XOR HX
LD LX,A
INC E
LD A,#88
CALL NZ,...1
LD HX,A
CPI
JP PE,...0
EX (SP),IX
POP DE
RET

...1
LD A,E
RRA
RRA
RRA
RRA
LD D,A
AND #0E
XOR E
AND #1F
RRA
JR C,...2
LD D,A
RRCA
RRCA
AND #C1
XOR E ;BIT 0,E=0!!!
RRCA
AND #F0
OR D
RET
...2
ADD A,A
ADD A,A
ADD A,A
ADD A,A
XOR D
AND #F0
XOR D
RET
DISPLAY $-CRC_CALC
═══════════════════════════════════════════

P.S. не разрешается публикация данного алгоритма в ZX NEWS.

С Вами был .┌─┐┌─┐┬┌ .┌─┐ aka J7n/4D
│┼─┼│ ├┴┐│├┤ jtn_собака_mail.ru
└┘┘ └└─┘┴ ┴└└─┘ sp...@fbi.com
-=- ZX MEDitation by Lara Croft 4.50
#Origin:Do not originate (2:5054/37.28)

Original.
Do not. [ZX] [Quake]

np: Blackmore's Night - Castles And Dreams

One day on Monday, February 25, 2002 at 1:30:04 pm Nikolaj Amosov wrote
a letter to All about FlashROM v5.1G:

NA> So, what would I like to see in the new version:
NA> 1. Deal with the FlashROM loader and remove the
NA> checksum check so that any user can make changes in
NA> ROM (like flashing your ROM-DISK with your favorite programs).

IMHO it would be better to make a program that generates a ROM file for GMX.

NA> 5. Make a detection of the enabled extended screen
NA> (#7EFD bit 3) when entering the shadow and turning it on if
NA> bit 3) when entering the shadow and turning it on if necessary when
NA> exit.

Moreover, this needs to be done only if we entered the shadow area using the Magic button. At
at the moment, the shadow switch turns off the extended screen whenever it is turned on, including
including when calling the functions Rst#08.

NA> 6. The most important thing is that whenever page 8 is turned on,
NA> reset the #DFFD port (extended memory) to zero, and restore its value at the
NA> output. This will allow
NA> to use additional memory, up to 2 MB, together with
NA> hard drive.

We need full support for extended memory, at least in the top window, and
so that I can write ram #39 in the shadow and everything works :)

NA> 7. Another very important change - hard connection
NA> of disk images tohard drive through the rst#08 functions, and not
NA> only through the monitor tools.

But what about programs that bypass this problem? If this is implemented,
then the emulation sector will be rewritten twice, which will affect the speed.
And programs using the corrected function, it turns out, will work
only on GMX, and on the same ProfPZU4.01 will be buggy.

NA> I think many GMX owners (if not all) will
NA> be very happy with this version of the ROM and will happily donate to the one
NA> who has it will do it.

They'll probably chip in :) Especially if it's not fixing glitches, but
bringing the shadow to mind (working in an extended screen, etc.)

I wish you good luck!
Sincerely, Fyodor Odegov aka FION.

One day on Wednesday, February 27, 2002 at 21:13:00 Vlad Sotnikov wrote a letter to
Nikolaj Amosov about FlashROM v5.1G:

VS> It’s curious, what benefits do users of
VS> GMX experience from using this same GMX?

They watch Pentagon demos, use programs that work with Pro memory,
and the 8th bank is not affected.

VS> Is there a lot of software for it?

Personally, I haven’t seen it:(( Although the matter can be fixed. The next messages are flying
a demo version of the commander for GMX, which I promised to do back in the summer, but then
somehow I got lazy, and the work slowed down:( Only recently something I finished it, corrected it and decided to show it all to the people :) So far we can only evaluate the appearance, connection of disks, etc. No copying or renaming yet.

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> SkyNet: 71:170/21

March 02, 2002 (and it was 12:54 then)
Dmitry Lomov in his letter to Nikolaj Amosov wrote:

DL> Now about the popular problem of calculating the CRC sector
DL> connections;). When studying the source text (ZX NEWS 54), several VERY stupid errors were identified, due to which the calculation of CRC
DL> now takes a little more time, but only 68 bytes of memory are spent!

I would like to draw attention to the fact that the procedure for calculating CRC published in my article (ZxNews54)
is entirely completely_ belongs to
comrade. MOA. There's not a single byte of mine there! I pestered him with requests to give me this procedure, and he brought it to me, civilly printed on a piece of paper. At the same time, he made a reservation that it was done hastily and it turned out to be a “mixture” of CRC_32 and CRC_16 :)

DL> P.S. Publishing this algorithm in ZX NEWS is not allowed.

Why is it not allowed in ZX_NEWS? Is it possible in other publications? :)

Vega / ex-Style Group. March 03, 2002

Saturday March 02, 2002 11:47:11 Vassili Klimov -> Sergey Zotov:

[cut dick]

FO> What about programs that circumvent this problem? If this
FO> is implemented, then the emulation sector will be rewritten twice, which
FO> will affect the speed. Yes, and programs that use the corrected
FO> function, it turns out, will only work on GMX, and on the same
FO> ProfPZU4.01 will be buggy.

It will be buggy only in one case - if we use the subprogram
ProfPZU. Its address in different versions should also be different. But there is one
option (I used it in Vega Commander): work directly with the screw
through the ports. The subroutine for calculating CRC (a fixed version flew through the echoes)
occupies quite a bit of memory. We need an additional subroutine for writing/reading a sector from a screw. The slow version takes less than a kilobyte.
In addition, there is another joke: for the commander we needed to know the
number of sectors/heads for the program to work correctly with the entire screw.
Here we work with only one sector, the auto-connection sector. And its
address is well known to us: it is the 2nd relative sector in the normal mode, and the 3rd in the LBA mode. Those. we need to set cil=0, head=0, sec=3 (or 4) and that’s it.
We don’t need to know the number of cylinders, heads or sectors - it will work
on any screw. And to find out whether the LBA mode is enabled or not, we only need tojust look at the value of the 6th bit of the Drive/Head Register (#FEBE). It not only
serves to enable LBA, but also shows when reading what mode we
are in. I checked.

NA> Let him do it first, and then we’ll pay after checking on
NA> real.

Or don’t pay :) The inertia of spektrumists has become the talk of the town...

NA> [REAL ZX]

Vega / ex-Style Group. March 04, 2002

VS> I would like to draw your attention to the fact that the procedure for calculating CRC published in my article (ZxNews54)
VS> belongs entirely to
VS> comrade. MOA. There's not a single byte of mine there! I pestered him with requests to give me
VS> this procedure, and he brought it to me, civilly printed on a piece of paper.
VS> At the same time, I made a reservation that it was done hastily and it turned out to be a “mixture” of CRC_32 and
VS> CRC_16 :)
there are no complaints against you;)

One day on Monday, March 4, 2002 at 22:36:00 Vlad Sotnikov wrote a letter
to Fyodor Odegov about FlashROM v5.1G:

FO>> And programs using the corrected9 function,
FO>> it turns out, will work only on GMX, and on
FO>> the same ProfPZU4.01 glitch.
VS> It will glitch only in one case - if we
VS> use the ProfPZU subprogram.

So many existing programs use it...

VS> But there is one option (I used it in Vega
VS> Commander): work directly with the screw through the ports.

And information for the shadow user (in the eighth bank) how do you register?
Now for correct operation, connecting the image is done according to the following scheme:

1) read the emulation sector
2) connect the image via RST8
3) make changes to the sector (including CRC)
4) write the sector in its place

If you remove the MOA error, then points 1,3,4 will be done via RST8. Thus
thus, a program working according to the old scheme will carry out these points twice
times, which is not so fraught :)
But here is a new program that works correctly on the intended subject, on
old versions of ProfPZU will skip these points, and glitches will be inevitable...

VS> CRC calculation subroutine (flying in echoes fixed
VS> option) takes up quite a bit of memory. We need
VS> additionallysubroutine for writing/reading a sector from
VS> screw. The leisurely option takes less than a kilobyte.

This is what I used (thanks!) in GMX-Comander :), but I still had to
enter information into the eighth bank manually

VS> And to find out whether the LBA mode is enabled or not, we just
VS> just need to look at the value of the 6th bit of the Register
VS> of the drive/head (#FEBE). It not only serves to
VS> enable LBA, but also shows when reading what
VS> mode we are in. I checked.

What are the ports in LBA mode and how are they addressed? And if you work with the
LBA screw in CHS mode, will the speed drop significantly, or does it not care?

VS> I'll buy a GMX soon, a lot of software will fall right away :)

We're looking forward to it.

I wish you good luck!

FO> What are the ports in LBA mode and how is it addressed? And if you work
FO> with an LBA screw in CHS mode, will the speed drop significantly, or is it all
FO> the same?

The speed should increase by 15-20 percent in LBA mode. Maybe
more, I don’t remember. As for addressing, I wrote in the article that I don’t really know this, and I still don’t know :) Someone Anton Gavrilenko knows exactly about this (he split SMUC, and from him, through me, port numbers went to the people). He then dictated LBA values ​​to me too, but I wrote it on the floppy disk cover, and in
1997 I was somehow not interested in LBA. I didn’t even know if I’d be able to do anything with the screw :) Then I regretted it, of course, but the piece of paper disappeared.
This Gavrilenko is now working for the Peters. You can find it there. The only possibility is that he doesn’t remember any of this anymore (it seems that I had another conversation with him later, and he was terribly surprised that it was he who told me the port numbers :) But nevertheless, we need to try it find...

FO>> work with an LBA propeller in CHS mode, will the speed drop significantly
FO>> or does it not matter to him?
VS> The speed should increase by 15-20 percent in LBA mode.

Why? The screw should not care.

Thursday March 15, 2002 at 00:27:00, Vlad Sotnikov => Fyodor Odegov:

VS> The speed should increase by 15-20 percent in LBA mode. Maybe
VS> more, I don’t remember. As for addressing, I wrote in the article that I don’t really know
VS> this
VS>, and I still don’t know :) Someone Anton Gavrilenko
^^^^^
Alexey
Gavrilenko
home phone number if I’m not mistaken is 399-7998

VS> (he split SMUC, and from him, through me, the port numbers went to the people).
VS> He then dictated the LBA values ​​to me too, but I wrote it on the cover of the floppy disk, and
VS> I was somehow not interested in LBA in 1997. I didn’t even know if I would be able to do something with the screw :) Then I regretted it, of course, but that piece of paper just disappeared.
VS> This Gavrilenko is now working for the Peters. You can find it there. Only
VS> there may be an option that he doesn’t remember any of this anymore (it seems that I somehow
VS> had another conversation with him later, and he was terribly surprised that it was he who told me
VS> the port numbers :) But nevertheless, we must try to find him...

VS> Vega/ex-Style Group.

VS>
VS> FIDO: 2:5030/885.34 ZXNET: 500:812/5.13 E-mail: veg...@mail.ru

Alexandr.

Vega/ex-Style Group.

<филфак-СПбГУ>
FIDO: 2:5030/885.34 ZXNET: 500:812/5.13 E-mail: veg...@mail.ru

FO>> I used it (thanks!) in GMX-Comander :), but
FO>> I still had to enter information into the eighth
FO>> bank manually
VS> What for? Do you know how I got around this feature in Commander? In
VS> principle, you also write about this. I trimmed the image according to
VS> RST 8 (the 8th bank turned out to be changed). And then
VS> modified the emulation sector. But RST 8 is just the data
VS> in bank 8 and registers! Why do this manually?

The fact is that in the shadow GMX extended memory and
screen are practically not supported. At the same time, whenever you enter the shadowbox (whether it be MAGIC or RST8), it
actively begins to turn on the turbo mode (apparently during interruptions, at least
you can’t turn it off with the button). And since in GMX the turbo is turned on not by reading from
7FFD, but by the 7th bit of the 7EFD port, on which the extended screen hangs, the
regular screen is turned on, because there is no check to see which screen was turned on at login.
That is, any access to the shadow operator procedures will turn on
the standard screen. And if we talk about connecting a partition via rst8, then
the extended screen in which my commander works will turn off for
some time, and this, IMHO, is inferior...
Therefore, I have to contact both the screw and the clock directly.
VS> The speed should increase by 15-20 percent in LBA
VS> mode.Maybe more, I don’t remember.

Can any LBA screw be addressed by CHS, or does CHS have any restrictions
on size?

March 18, 2002 (and it was then 21:30)
Fyodor Odegov in his letter to Vlad Sotnikov wrote:

FO> The fact is that in the shadow GMX, extended
FO> memory and screen are practically not supported. At the same time, at any entrance to the shadow (be it at least
FO> MAGIC, or RST8), it actively begins to turn on the turbo mode (apparently on
FO> interruptions, at least it won’t be possible to turn it off with a button). And since
FO> in GMX the turbo is turned on not by reading from 7FFD, but by the 7th bit of the 7EFD port, on
FO> on which the extended screen hangs, the normal screen is turned on, because
FO> there is no check to see which screen was turned on at entry. That is, when
FO> any access to the shadow operator’s procedures, the standard
FO> screen will be turned on. And if we talk about connecting a partition via rst8, then the extended
FO> screen in which my commander works will turn off for some
FO> time, and this, IMHO, is inferior... Therefore, we have to
FO> access both the screw and the clock directly.

It’s not bad to work through ports. But you can still somehow try to get around this feature. Otherwise, in general, I wouldn’t want to lose RST 8 :(

VS> Lately we have begun to recover from the descriptiveness. Sergei Zerov works very actively there
VS> - they bring everything to him and carry payments for repairs - i.e. he is not left without
VS> work. Here a person recently wrote in an echo that his alter
VS> burned out - I strongly advised him to turn to the scorpions. So they
VS> promised to send him an alter by mail - he was very surprised :) So they
VS> continue to work with Speck...
this makes me happy. I wonder if they are releasing new boards? Just look, the software will be fixed
finally;)

JTN/4D

VS>> CHS. There,
VK> I would say more - with CHS the maximum visible is 500mb, and with LBA - 128gb

Why is this? 512MB - write-in BIOS limitation.

SZ> Oleg Grigoriev.

nope. Just because I wrote for it doesn’t mean that I have it. :)

WBR, Oleg.