Jump to content
IGNORED

1050 Happy Clone by Irata Berlin and some Questions 'bout this.


dash_rendar

Recommended Posts

Hi,

recently bought a 1050 where a Happy-Clone from IRATA (Berlin Germany) is installed.
It also runs flawlessly, only it has a few more contact surfaces (see picture), and I can not find ANYWHERE documents.
So I wanted to know if any of you still have information about it (Schematics, Switches like "Speed on/off" a.s.o.)

It is also recognized by Happy-Tooldisk 1 as Happy, and the tests run completely, except for ROM positive - But I had the same with another Happy-Clone that it hooked right there, which is also logical, because the values of the EPROM are not 100% those of the origin.
I just want to know what else I can do with it, that is, what else I can connect and above all where on the PINS.

 

And important : What features are included?

 

tya for reading ?

1050-1.jpg

Link to comment
Share on other sites

Thanks for sharing @dash_rendar. Could you share a dump of the EPROM? There are a number of other happy ROMs, 2 official, 3 or more derivatives from other clone boards that have been posted over the years. Then we can compare with what others have shared, and see what the changes are. Some were modified to fix bugs like the ultraspeed non-buffered single density write corruption, while others added new functionality like a track number display and faster stepping rate. This causes the original happy firmware test to show "fail". IRATA Verlag may have originally provided a modified utility disk to account for the different ROM.

 

Most clone boards I've seen do not bother to replicate the connector to support the "Happy Controller" add-on which provided switches for write protect bypass, track buffer toggle, and a tri-color LED to indicate write protect status.

 

Since I see 5 through-holes, my guess is it's for an unpopulated happy controller connector. I believe the top most pin (through-hole on yours) will be +5V/Vcc on the original happy board, maybe you can test if your board matches?

  • Like 1
Link to comment
Share on other sites

3 hours ago, dash_rendar said:

i have an EPROM-Burner, but i don't believe, that i could make a dump with that *ggg*. Is there any program which are making a dump directly on the ATARI ?

Yes, there is: ?

 

Although the limitation of reading the ROM this way is that there are four bytes of the ROM that cannot be reliably read by this software as they are used for bank switching the ROM. Fine for a working copy, but less exact for forensic comparison. Other modified happy ROMs out there have random bytes in these 4 locations which suggests the dump they started with was acquired using a similar software method.

 

Maybe in the future @E474 can explore tweaks in timing or double-reading those bytes with delay to allow bank switching complete and allow it to read them accurately, but I'm not sure if it's possible. The dump process reads out blocks from the ROM, not just single bytes, so maybe one would have to craft the range alignment to request one byte but not the other at the start or end of the requested block...

 

Which EPROM programmer do you have? See if it supports any brand of 27C64 or 28C64 chips (8Kx8)

Link to comment
Share on other sites

Hi,

 

  Thanks @Nezgarfor the plug for dump1050 - I think it's much more preferable to dump the ROM via software than taking apart a working board and dumping with an EPROM reader (these boards are getting on a bit). I also think it's handy to have a backup of the ROM in case it goes bad in the future. It's also good for software preservation.

 

    There are a couple of locations that can't be read via software ($FFF8 and $FFF9, if I recall correctly), these locations are used for triggering a bank selection. The value that you get isn't necessarily the value in the EPROM, but what happens to be on the data bus given the electronics for your board. Even if there was a consistent value returned, it wouldn't necessarily be the value in the EPROM. 

 

   If you want to compare different ROM dumps, you should just compare the bytes that can be reliably dumped, these bytes are the only ones that the processor can actually access anyway. If you compare different dumps using a CRC/hash value, then it will look like the files are different, but this isn't a significant difference, it's only significant if the data that can be dumped reliably is different. 

 

   If you want to make a physical dump of the ROM using an EPROM reader, you should be able to read these hidden bytes, but you'll be reading data that the processor can't, and you also run the risk of accidentally damaging the board.

 

    I guess the upshot of all this is that if you are interested enough to find out about the ROM contents of your upgrade, you'll also find out about the bytes that can't be read, and that if you want to compare ROM dumps, you'll only be comparing bytes that the processor can read.

 

    There's more info on the thread that @Nezgar kindly linked to, and also on the github page with the sources.

 

   Hope this helps!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...