NO$CASH Kernel Clone - New Expansion ROM Version
NO$CASH Kernel Clone - New Expansion ROM Version
Hiya, the new version of my kernel clone is now also working as Expansion ROM (ie. it can be used with regular Xplorer & Datel cheat devices).
The binaries can be found in no$psx v2.0 (debug version) --> Utility --> Remote Access menu. There are several options for installing the file:
- You can extract the raw ROM Image (and then use whatever EEPROM burning tools you might have).
- You can extract the installer as EXE file (and run that file on the playstation to install the kernel clone).
- You can directly upload the installer via parallel port (in case anybody still has a PC with parallel port).
The kernel clones replaces the whole internal kernel and user interface. Some (dis-)advantages might be that the GUI looks different, the clone is written in ASM, so it's a lot faster than Sony's original kernel (though most games are synced with vblank or cdrom timings, so there may be not too much noticable differences - apart from cases like memory card access, which should be ways faster with the clone).
Some extra features are secret unlock commands for booting homebrew discs, plus the new Chipless Modchip feature for doing the thing faster (via minimal hardware mods). Plus a built-in VCD Player for PSX.
Parallel Port features
And, built-in parallel port support for cheat devices (yes, I am still using parallel ports, and if you have one, you will probably agree that they are still faster than more popular things like serial ports (at least with my new uploader software, which is a lot faster than the original Xplorer uploads)). The main feature would be uploading EXE files (via no$psx Utility --> Upload) feature, allowing to test homebrew code on real hardware without needing to burn CDRs.
- For Xplorer carts, the kernel clone supports most of the original xplorer functions.
- For Datel carts, the kernel clone supports only the basic boot functions.
Note: Datel carts are somewhat incompatible with parallel ports. Which is half true, but they are almost compatible, and they can be made fully compatible with minor modification (aka "FiveWire" hardware mod). With that mod, the parallel port upload should even work without my kernel clone installed. Namely it should work if you have the original Action Replay firmware installed (which is so slow that it should work without certain handshaking signals), on the other hand it won't work if you have Caetla installed).
The binaries can be found in no$psx v2.0 (debug version) --> Utility --> Remote Access menu. There are several options for installing the file:
- You can extract the raw ROM Image (and then use whatever EEPROM burning tools you might have).
- You can extract the installer as EXE file (and run that file on the playstation to install the kernel clone).
- You can directly upload the installer via parallel port (in case anybody still has a PC with parallel port).
The kernel clones replaces the whole internal kernel and user interface. Some (dis-)advantages might be that the GUI looks different, the clone is written in ASM, so it's a lot faster than Sony's original kernel (though most games are synced with vblank or cdrom timings, so there may be not too much noticable differences - apart from cases like memory card access, which should be ways faster with the clone).
Some extra features are secret unlock commands for booting homebrew discs, plus the new Chipless Modchip feature for doing the thing faster (via minimal hardware mods). Plus a built-in VCD Player for PSX.
Parallel Port features
And, built-in parallel port support for cheat devices (yes, I am still using parallel ports, and if you have one, you will probably agree that they are still faster than more popular things like serial ports (at least with my new uploader software, which is a lot faster than the original Xplorer uploads)). The main feature would be uploading EXE files (via no$psx Utility --> Upload) feature, allowing to test homebrew code on real hardware without needing to burn CDRs.
- For Xplorer carts, the kernel clone supports most of the original xplorer functions.
- For Datel carts, the kernel clone supports only the basic boot functions.
Note: Datel carts are somewhat incompatible with parallel ports. Which is half true, but they are almost compatible, and they can be made fully compatible with minor modification (aka "FiveWire" hardware mod). With that mod, the parallel port upload should even work without my kernel clone installed. Namely it should work if you have the original Action Replay firmware installed (which is so slow that it should work without certain handshaking signals), on the other hand it won't work if you have Caetla installed).
Hey, I want to install this to an Expansion ROM. I burned the installer to CD and it boots fine.
However, it doesn't seem to detect any of my devices.
It keeps saying "Found single chip". I've tried this with an Xploder, Xploder FX and a Datel clone.
Is there anything I'm missing?
Edit:
I also tried creating an xflash CD with this ROM but the required tool 'romfile.exe' says ' Invalid ROM : PSX-XBOO.rom'.
Edit2:
Okay, I'm an idiot :p
Trying again, I used the correct Expansion ROM version installer and burned that to disk.
It has a different problem though: In no$psx, it simply hangs at boot.
On real hardware, it does the same.
The problem is in the PSX-EXP.EXE already (ie: It hangs with the .exe and with my created CD ROM).
If I try to use the PSX-EXP.ROM with romfile.exe (for x-flash), it complains about 'Invalid ROM' again.
Also the file size is weird, at 95kB.
Edit3 (sorry):
Got it working!
I loaded PSX-EXP.ROM into no$psx and then choose the menu option 'Create currently loaded expansion rom installer (EXPAND.EXE)'.
This executable worked in no$psx so I burned it to CD and it booted up on real hardware.
It detected my Xploder just fine and installed to it!
However, it doesn't seem to detect any of my devices.
It keeps saying "Found single chip". I've tried this with an Xploder, Xploder FX and a Datel clone.
Is there anything I'm missing?
Edit:
I also tried creating an xflash CD with this ROM but the required tool 'romfile.exe' says ' Invalid ROM : PSX-XBOO.rom'.
Edit2:
Okay, I'm an idiot :p
Trying again, I used the correct Expansion ROM version installer and burned that to disk.
It has a different problem though: In no$psx, it simply hangs at boot.
On real hardware, it does the same.
The problem is in the PSX-EXP.EXE already (ie: It hangs with the .exe and with my created CD ROM).
If I try to use the PSX-EXP.ROM with romfile.exe (for x-flash), it complains about 'Invalid ROM' again.
Also the file size is weird, at 95kB.
Edit3 (sorry):
Got it working!
I loaded PSX-EXP.ROM into no$psx and then choose the menu option 'Create currently loaded expansion rom installer (EXPAND.EXE)'.
This executable worked in no$psx so I burned it to CD and it booted up on real hardware.
It detected my Xploder just fine and installed to it!
This has to be the most impressive 'homebrew' software on PSX ever.
I just tested a few games and eventhough I don't know how they use the kernel functions, they *feel* faster.
The old Sony QA disk probably uses kernel CD ROM access functions. It reports about 20% faster access times on the same console, just with this new kernel
One thing I noticed is that the new Memory Card access speeds will be an issue.
Out of 2 games with Memory Card functions that I tested, both read old saves fine but error out when writing new ones (or overwriting).
I did manage to get them working as normal by selecting the '0.5' CRC option though, so that's great.
To help protect people's save games, I recommend defaulting to that setting in an eventual new release.
For now, everyone that's testing this new kernel, remember to use disposable save games!
The games tested were Chrono Cross and Tomb Raider 5, both NTSC.
I just tested a few games and eventhough I don't know how they use the kernel functions, they *feel* faster.
The old Sony QA disk probably uses kernel CD ROM access functions. It reports about 20% faster access times on the same console, just with this new kernel
One thing I noticed is that the new Memory Card access speeds will be an issue.
Out of 2 games with Memory Card functions that I tested, both read old saves fine but error out when writing new ones (or overwriting).
I did manage to get them working as normal by selecting the '0.5' CRC option though, so that's great.
To help protect people's save games, I recommend defaulting to that setting in an eventual new release.
For now, everyone that's testing this new kernel, remember to use disposable save games!
The games tested were Chrono Cross and Tomb Raider 5, both NTSC.
Installer EXE
Oops, yes, there's a stupid mistake: I forgot to zeropad the EXE to next 800h-byte boundary (the installed stub is 2800h bytes, but the size of the appended ROM-image isn't properly aligned). Theoretically it should have worked in a single step, as so:
1) Create nocash expansion rom installer (PSX-EXP.EXE)
But as that's bugged, it should work with your workaround, ie. these 3 steps:
1) Create nocash expansion rom as raw image (PSX-EXP.ROM)
2) Load PSX-EXP.ROM via "cdrom" filemenu (this will internally allocate 20000h bytes for it, fixing the issue)
3) Create currently loaded expansion rom installer (EXPAND.EXE)
The third step was normally intended for third-party roms (like datel/caetla/xplorer firmwares, for cases when existing burning tools don't work with certain chipsets, like the xplorer carts with two flash chips in them).
Memory Cards
Damnit, I've used the clone on real hardware for some years, and don't remember hitting any difficults. The "Card Sectors per Frame" option has four settings:
0.5 (normal/slow)
1.0 (fast)
More than 1 (faster)
No Chksum (fastest)
If "0.5" is working is fine, it's just not very fast (as in original kernel, it's restricted to access memory card 1 only in even video frames, and the memory card 2 only in odd frames, which is nonsense, especially when you have only one memcard).
Did you try the middle two settings, too? The "1.0" removes the above restriction (and shouldn't cause issues). The "More than 1" disables vblank irqs and reads data without vblank sync'ing (maybe that could go wrong in some cases, it should cause data corruption since it's affecting only read operations). And the "No Chksum" is doing the same, plus omitting reading the checksums (and especially the leading zero-padding prior to the checksums, which is making directory accesses so slow).
What went wrong exactly? Did you get a write error message, or did the game just hang? And did it actually write anything to the card or cause data corruption on the card?
Oops, yes, there's a stupid mistake: I forgot to zeropad the EXE to next 800h-byte boundary (the installed stub is 2800h bytes, but the size of the appended ROM-image isn't properly aligned). Theoretically it should have worked in a single step, as so:
1) Create nocash expansion rom installer (PSX-EXP.EXE)
But as that's bugged, it should work with your workaround, ie. these 3 steps:
1) Create nocash expansion rom as raw image (PSX-EXP.ROM)
2) Load PSX-EXP.ROM via "cdrom" filemenu (this will internally allocate 20000h bytes for it, fixing the issue)
3) Create currently loaded expansion rom installer (EXPAND.EXE)
The third step was normally intended for third-party roms (like datel/caetla/xplorer firmwares, for cases when existing burning tools don't work with certain chipsets, like the xplorer carts with two flash chips in them).
Memory Cards
Damnit, I've used the clone on real hardware for some years, and don't remember hitting any difficults. The "Card Sectors per Frame" option has four settings:
0.5 (normal/slow)
1.0 (fast)
More than 1 (faster)
No Chksum (fastest)
If "0.5" is working is fine, it's just not very fast (as in original kernel, it's restricted to access memory card 1 only in even video frames, and the memory card 2 only in odd frames, which is nonsense, especially when you have only one memcard).
Did you try the middle two settings, too? The "1.0" removes the above restriction (and shouldn't cause issues). The "More than 1" disables vblank irqs and reads data without vblank sync'ing (maybe that could go wrong in some cases, it should cause data corruption since it's affecting only read operations). And the "No Chksum" is doing the same, plus omitting reading the checksums (and especially the leading zero-padding prior to the checksums, which is making directory accesses so slow).
What went wrong exactly? Did you get a write error message, or did the game just hang? And did it actually write anything to the card or cause data corruption on the card?
Memory Cards:
Yes, I've tried the other options as well. The problem immediately starts at 1.0 (fast).
tested: Tomb Raider 5, Chrono Cross, Tomb Raider 2, PSX-XBOO itself (tried to copy a savegame > Card I/O Error)
Yes, I've tried the other options as well. The problem immediately starts at 1.0 (fast).
tested: Tomb Raider 5, Chrono Cross, Tomb Raider 2, PSX-XBOO itself (tried to copy a savegame > Card I/O Error)
How to use this bios clone in others emulators ?
PSX-XBOO.ROM is the bios file or image for x-flash?
I've tried to extract bios using Shendo bios dumpper,is not working in others emulators example: xebra, ePSXe...
PSX-XBOO.ROM is the bios file or image for x-flash?
I've tried to extract bios using Shendo bios dumpper,is not working in others emulators example: xebra, ePSXe...
Hmmmm, how could that happen? Looks as if I didn't test things too well. Or maybe it happens only on certain memory cards, or I've just screwed it up.rama3 wrote:Memory Cards:
Yes, I've tried the other options as well. The problem immediately starts at 1.0 (fast).
tested: Tomb Raider 5, Chrono Cross, Tomb Raider 2, PSX-XBOO itself (tried to copy a savegame > Card I/O Error)
I'll check what's wrong next week. Good to know that it starts with the 1.0 setting! My current theory is that I'll just need to insert a small delay between the memory card commands (when switching the card select line off, and back on - so that the card will realize that it's newly selected for receiceiving a new command).
Yes that's the bios. Moment, as far as I remember it's only 256Kbytes, right? If you want to burn it to a 512K chip (or use it in an emulator that expects 512K files), double the filesize by copying the same data in lower and upper half of the file, using a hex editor, or copy /b at command prompt.pepe wrote:How to use this bios clone in others emulators ?
PSX-XBOO.ROM is the bios file or image for x-flash?
Hm, it looks like the settings don't get saved reliably, or they don't get read on startup reliably.
This worked yesterday but today the cart always 'forgets' settings after a reset or cold start.
Tested with 2 consoles and I made sure all EXP pins made good contact.
I also tried reflashing the Xploder, in case the EEPROM was the issue, but that worked fine.
Or is it always saving to the same EEPROM region and that region might have died?
Update: Oh, it works when a Memory Card is present!
Are the settings stored on there, maybe?
This worked yesterday but today the cart always 'forgets' settings after a reset or cold start.
Tested with 2 consoles and I made sure all EXP pins made good contact.
I also tried reflashing the Xploder, in case the EEPROM was the issue, but that worked fine.
Or is it always saving to the same EEPROM region and that region might have died?
Update: Oh, it works when a Memory Card is present!
Are the settings stored on there, maybe?
Yes, settings are stored in one of the unused memory card sectors.
Storing them in bios/expansion memory would be a bit more difficult: Won't work with chips aren't stored in the chip ID list, won't work with PROMs or UV-EPROMS, and I haven't researched what kind of erase-sector-sizes the different chips have (only used erase-entire so far) (and for settings, the chips should ideally support erasing only 80h-bytes, but some chips might insist on erasing much bigger memory blocks as smallest unit).
Storing them in bios/expansion memory would be a bit more difficult: Won't work with chips aren't stored in the chip ID list, won't work with PROMs or UV-EPROMS, and I haven't researched what kind of erase-sector-sizes the different chips have (only used erase-entire so far) (and for settings, the chips should ideally support erasing only 80h-bytes, but some chips might insist on erasing much bigger memory blocks as smallest unit).
Ah, thanks for explaining. It's nice you found a way not to waste a Memory Card block
this bios clone not work on any emulator(except nocash emulator), probary because the cdrom unlock commands freezes the emulatorYes that's the bios. Moment, as far as I remember it's only 256Kbytes, right? If you want to burn it to a 512K chip (or use it in an emulator that expects 512K files), double the filesize by copying the same data in lower and upper half of the file, using a hex editor, or copy /b at command prompt.
how to disable cdrom unlock commands in the bios clone ?
Are you sure those other emulators are prepared for a BIOS clone?
It's very likely they look for the known dumps via some hash.
It's very likely they look for the known dumps via some hash.
You have made it a 512K file, didn't you?
The secret unlock commands were added with no$psx v1.9, you could download the older versions and try if they work. Even the older versions are writing to debug info stuff to unused I/O ports.
Theoretically, some/many/all other emulators should just ignore that I/O (and secret unlock) stuff. Or do you get error messages where they are specifically complaining about such things?
The official kernel versions are widely compatible with each other, and emulators don't really need hashing them to know which version they are running on... unless they are somehow patching/hooking some kernel functions.
Are there any win9x compatible psx emulators? Then I could test it myself. Or, contact the other emu authors, maybe they can tell why their emus don't work - or if there's a bug/problem in my clone bios.
The secret unlock commands were added with no$psx v1.9, you could download the older versions and try if they work. Even the older versions are writing to debug info stuff to unused I/O ports.
Theoretically, some/many/all other emulators should just ignore that I/O (and secret unlock) stuff. Or do you get error messages where they are specifically complaining about such things?
The official kernel versions are widely compatible with each other, and emulators don't really need hashing them to know which version they are running on... unless they are somehow patching/hooking some kernel functions.
Are there any win9x compatible psx emulators? Then I could test it myself. Or, contact the other emu authors, maybe they can tell why their emus don't work - or if there's a bug/problem in my clone bios.
always shows the black background color in all emulators, bios from nocash 1.8 in xebra with a cd inserted shows "press select for bootmenu" the pad not respond, bios from nocash 1.8 in psxfin: i have inserted a disk image seconds before the error message and shows the boot menu, the bios clone shows: *** unknown disk type 28000008 ***The secret unlock commands were added with no$psx v1.9, you could download the older versions and try if they work
ePSXe and psxfin works officially in win98Are there any win9x compatible psx emulators? Then I could test it myself
pcsx-r probary works in win98,xebra is not supported officially (some unsuported apps works with kernel ex)
psxfin is the only emulator shows error messages related with cdrom commands: (same problem in bios: no$psx v1.8)Theoretically, some/many/all other emulators should just ignore that I/O (and secret unlock) stuff. Or do you get error messages where they are specifically complaining about such things?
cdrom: unhandled test command 22
cdrom: unhandled test command 22
i have tested the bios clone no$psx v2.0 in emulators:
xebra
pcsx-r
ePSXe
psxfin
SSSPSX
popstarter
Im having issues, burning the rom onto this PAR Clone cartridge. It detects the chip & is ready to burn but after it flashes the rom to the cart & resets the console, the cart's rom is blanked out/softbricked & have to reflash it with kHn's XFlash mod with Unirom or something else thats 128K. I tried making a Xflash ISO with the NO$Cash rom but it claims to say its an invalid rom, otherwise Im not sure what to do. Thanks!
SST29EE010 is not siutable for no$cash BIOS clone cause it has no such amount of memory space that BIOS clone needed. 29EE010 is 128kByte EEPROM but you need xxxx020 (256kByte) or xxxx040 (512kByte)
EEPROM. Also cause of no$cash BIOS is 256kByte weight and you want it to use with 512kByte IC you need to create a new image by clonning BIOS image twice in HEX editor (for no$cash BIOS to become 512kByte). If there is a need I can upload such "duplex" image here.
A Datel device I have ("Equalizer") originally came with an unsupported SST flash.
I noticed that some Chinese memory cards use SST29LE020 EEPROMs for storage.
The devices look very similar, so I just went ahead and swapped them, using a heat gun.
This worked really well. The installer detected / burned the new EEPROM without issue
One odd thing about the installer is that it says it detects 00040000, not the 00020000 it says it requires.
Probably a glitch, as the LE020 should be a 256k device, as required.
I noticed that some Chinese memory cards use SST29LE020 EEPROMs for storage.
The devices look very similar, so I just went ahead and swapped them, using a heat gun.
This worked really well. The installer detected / burned the new EEPROM without issue
One odd thing about the installer is that it says it detects 00040000, not the 00020000 it says it requires.
Probably a glitch, as the LE020 should be a 256k device, as required.
Mine has a 29EE020.
X-Flash bricked it, and the X-Flash mod was unable to restore its original rom.
Fortunately noCash's flasher rescued it and it now has its original firmware back . Can't remember how the EEPROM is mapped though.
Thanks nocash !
X-Flash bricked it, and the X-Flash mod was unable to restore its original rom.
Fortunately noCash's flasher rescued it and it now has its original firmware back . Can't remember how the EEPROM is mapped though.
Thanks nocash !
That's exactly the one I just swapped the SST on. So yeah, those definitely work. I wonder what the ASIC even does.
And what's with the small extra IC (serial EEPROM?)
And what's with the small extra IC (serial EEPROM?)
-
Administrator Verified
- Admin / PSXDEV
- Posts: 2683
- Joined: Dec 31, 2012
- I am a: Shadow
- PlayStation Model: H2000/5502
Well I got the NO$PSX kernel on my Xplorer (had to also wire PIN 16 of the DB25 port to PIN 2 of the PlayStation Parallel Port), and I can upload PS-EXE's to it, but can it actually debug in real-time the PS-EXE you've uploaded? It's also missing Psy-Q Symbol File decoding which I assume is the next big thing in the update NO$PSX 2.1 update.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
Who is online
Users browsing this forum: No registered users and 0 guests