ROMAN 2

[TotO]

I think that is not related to a custom FW. (but, I should be wrong)
Trying to put a standard FW on the X-MEM for booting with should cause the same problem. (i.e. a 464 with FW3.0 on the X-MEM)
If yes, that means the interrupts are not disabled while writing... Else, help... SyX !!!!!!!! 

[CraigsBar]

I think that is not related to a custom FW. (but, I should be wrong)
Trying to put a standard FW on the X-MEM for booting with should cause the same problem. (i.e. a 464 with FW3.0 on the X-MEM)
If yes, that means the interrupts are not disabled while writing... Else, help... SyX !!!!!!!! 

Confirmed... using a standarg Basic 1.0 or 1.1 installed on the xmem I get the same issue when booting from the external firmware. so I guess the issue is simply that roman does not play nice with external firmwares. and that would seem to fit TotO's diagnosis.

[CraigsBar]

  OMH! That would be way to complicated to me. And I don't want to need to fire up the PC just to be able to burn a ROM on CPC. If you need your PC, then get the Flash to your PC Flasher and you can have all the comfort you want.

Well that is not strictly easier, pulling flash chips and popping them into an external programmer sounds like a royal PITA to me, but I guess that is not the point you are making... But whilst we are at it I hardly need to turn the Mac on, it is all but never turned off, and if for some reason I have the Mac Pro off then my Macbook Pro boots in under 8 seconds. hardly a long wait.

Well, I can only tell you what I think. If I don't like the situation then I change it by myself. That was the reason I made FutureOS.
We all have a different taste, maybe you should make your own ROM flasher?

Believe it or not we are not all coders, some of us are "simple users" we help out where we can with bug reports and feature requests. But when it comes down to it we have no skills when it comes to making code changes etc.


Building a cartridge or a case mod I can do, I am even looking forward to making the new Plus carts for Fluff Anniversary release. I know exactly what cases I am going to build. but these things I can do.


craig

[TFM]

Oh well, we all got our strength and abilities. But not everybody in the same field.    Feedback and feature requests are very welcome.
For example since ROManager 1.4x up to 1.8x I basically added feature requests, like hotkeys for standard functions or pressing a single key to see all ROMs. That's all included now. So  thanks to every body who gives critics and feedback. It's appreciated. On the other hand some people (German scene especially) are only good in bitching at others productions, and that's a let down. Here in the Wiki the situation is rather positive and I think also very productive.
But I'm getting off topic...

[Pentagon]

You probably got one from the first X-MEM batch, they have the Winbond Flash. Later versions use the SST Flash, since it's getting harder and harder to get the Winbond Flash.

Thank you for the hint. I have looked at my X-Mem now and it is a "SST 39F040" Chip in the socket. It is really working fine with Roman 2.0

Regards
Tom

[TotO]

For example since ROManager 1.4x up to 1.8x I basically added feature requests, like hotkeys for standard functions or pressing a single key to see all ROMs. That's all included now.

I think that you have mainly improved the way to detect, lock/unlock and program the flash chips.
About the "TotOs X-MEM" text, you should remove my name or replace it by ACME.

[CraigsBar]

Thank you for the hint. I have looked at my X-Mem now and it is a "SST 39F040" Chip in the socket. It is really working fine with Roman 2.0

Regards
Tom

using external firmware, or switched to the internal one?

[Pentagon]

using external firmware, or switched to the internal one?

Hi, i am just using the original internal CPC Firmware and not a customized external. It is working at CPC464 and CPC6128.

Regards
Tom

[SyX]

I think that is not related to a custom FW. (but, I should be wrong)
Trying to put a standard FW on the X-MEM for booting with should cause the same problem. (i.e. a 464 with FW3.0 on the X-MEM)
If yes, that means the interrupts are not disabled while writing... Else, help... SyX !!!!!!!! 

Well, as i told in the P&P thread, if somebody asks politely instead of saying is a shit and doesn't work, i could try to discover why fail... but if nobody asks, i can not do anything.

I have taken a fast look (5 minutes) and the bug in ROMAN is because uses the zone in $BE00, exactly the same place used by the FW3.15 for storing the pointers to the 32 roms (one of the few changes to the rom the firmware makes  ).

Remember the thread of patching the firmware to use more than 16 roms, because booster was an awful hack, and we decided to put a table for 32 roms in other place and i chosen this place, because is free and before the Amsdos variables in $BE40.

I'm not going to be able to look deeper in a while, because i'm starting my university tests and few work presentations. But at least, there is more problems, it's only to change those address to a free zone and the program should work in FW3.15, if somebody wants a fast patched version, they can go ahead and change all the references to $BExx (xx < $40). And publish a diff or remember to ask permission for releasing this pacthed version.

[CraigsBar]

@SyX I don't think I ever said Shit it does not work, and if this thread caused offence I appologise. Although I don't really see how the 32 rom mods to FW 3.15 can cause this. As detailed in my tests last night, when the external FW on the X-Mem has an un modified 464 or 6128 image the result is the same. ROMAN crashes and fails to program the xmem correctly. Also when I use my old FW 3.14 cartridge in my 6128 plus it works fine, but again not once the xmem is toggled to use the external FW.


It seems that the issue is simply that roman is not happy with an external FW but perfectly fine with an internal one, be that FW original or modified.


Again I appolgise fo any offence I certainly did not mean this to anyone


Craig

[SyX]

@CraigsBar: Don't feel bad, you don't need to apologise, because i was  talking about a thread in P&P.

As you have discovered, this change for supporting 32 roms (more exactly for not having memory corruption when more than 16 roms that reserve RAM, as Protext, are used) happened between 3.14 and 3.15. And it's only bad luck that FW and ROMAN chosen to use the same ram zone.

Why did i change the zone? because in the original zone there is only a hole enough for 16 roms (32 bytes) and we need exactly the double, there is not a lot of places with 64 bytes between the ram firmware variables.

Maybe i should think for the FW 3.16, to add a configuration (similar to the RAM disk size) where you can choose between use 16 (in the old zone) or 32 roms.

The other thing is that you can have two different flash chips in a X-Mem, even we could have a third one in a future release (i'm not joking ). Then the flashing software, as TFM's ROManager makes, check before of flashing for the chip in the board.

[TFM]

I think that you have mainly improved the way to detect, lock/unlock and program the flash chips.
About the "TotOs X-MEM" text, you should remove my name or replace it by ACME.

OK! Will be done for 1.89 ;-)

[TFM]

I have taken a fast look (5 minutes) and the bug in ROMAN is because uses the zone in $BE00, exactly the same place used by the FW3.15 for storing the pointers to the 32 roms (one of the few changes to the rom the firmware makes  ).

OMG! Why in the world must a simple tool use that area? There is enough RAM left below &AXXX. Please all coders leave the Firmware area to the firmware!!! 

[Executioner]

I have taken a fast look (5 minutes) and the bug in ROMAN is because uses the zone in $BE00, exactly the same place used by the FW3.15 for storing the pointers to the 32 roms (one of the few changes to the rom the firmware makes  ).

So does ParaDOS for large Drive A format block allocation table since ROMDOS, Ultraform and ParaDOS41 formats require up to 50 bytes. I'm not sure there was anywhere else it could go.

[TFM]

Gentlemen you gotta talk to each other and find the right bytes to make it all running together.     


Maybe steal a bit of the stack?

[SyX]

So does ParaDOS for large Drive A format block allocation table since ROMDOS, Ultraform and ParaDOS41 formats require up to 50 bytes. I'm not sure there was anywhere else it could go.

Sure, for rom code, we haven't a lot of places to put data, jajaja.

I'll take another look for places to hide the extra 16 rom pointers for the next version of my firmware hack

[CraigsBar]

Sure, for rom code, we haven't a lot of places to put data, jajaja.

I'll take another look for places to hide the extra 16 rom pointers for the next version of my firmware hack

Would it also be possible to implement the "fix" suggested by @Executioner and pass a |drive with no parameters on to Parados (or AmsDos) instead of returning an error?


Thanks


Craig.

[radu14m]

any ideea why do i get this garbage on the screen ?

[TotO]

Probably the program is going to explode... Check the nice "dynamite" color cursor on the bottom-right of the screen. 

It look to be ROMAN code that fill the ROM list. Nice "buffer overflow". 

[radu14m]

The nice "dynamite" color cursor on the bottom-right of the screen is the reflection from the HXC light
No explosion


anyway, even if roman 2 fail to write the ROM"s, with the HELP RSX command i see that something was written.
what"s this ? ( 0.00 FOREGROUND )



should i use another ROM utilities ?


Tried also with the FLASH command, same situation. A written ROM file appears in the same way :0.00 FOREGROUND

[TotO]

I suggest you to remove the BOOSTER ROM to see what happening...

You can test with the FLASHER program from the X-MEM floppy to see the ROM list too.
(best, using the EDITOR program to see the ROM content)

[radu14m]

it did not help.
i try both method !

[CraigsBar]

it did not help.
i try both method !

re-run init from the xmem disc to completely wipe it and reinstall perhaps?

[radu14m]

yes, i did that.


rescue
init
install.


several times.

[CraigsBar]

yes, i did that.


rescue
init
install.


several times.

damn. TotO? Corrupted (or pooched) flash chip perhaps. Mine does that exact same thing when I try to flash with Roman from fw3.15 but after a reboot all is happy again.