search

MEGA65 / open-roms

A project to create unencumbered open-source ROMs for use on selected retro computers
Other
263 stars 18 forks source link

IEC improvements and misc changes #27

Closed FeralChild64 closed 5 years ago

FeralChild64 commented 5 years ago

See STATUS.md for the current status. IEC still needs quite some work, but I expect to have much less time in the upcoming few weeks.

gardners commented 5 years ago

Wow! That looks like a pile of work. Well done! Can you please provide a report on the unexplained similarities at the current point? We need to make sure we have those all covered off before merging.

FeralChild64 commented 5 years ago

And the IEC stack is not even fully compatible yet... I really don't know when I'll finish this. Report is here. The longest one (21 bytes) is definitely my small jump-table in via_vector.s - a workaround for missing indirect JSR, it seems Commodore engineers had exactly the same idea. Should I shuffle the order to silence the tool?

[edit1] Started a branch to explain similarities / rework the code - here

[edit2] Most of the longer similarities are related to $DD00 (CIA#2 port #A) bit manipulations.

gardners commented 5 years ago

Hello,

Yes, do what you can to avoid similarities where possible. Incidently, the C65 and M65 do have indirect JSR instructions.

For any match of > 3 bytes, please create an explanation file for each, so that I can look at those as part of the pull. This is important for us from a copyright infringement avoidance perspective, that we justify any significant similarity. Even for the 3 byte ones, it would be great to have them in there. Often this will just be a single instruction (not copyrightable) or fragments of instructions. This is fine, but we should mark them as such, so that we are showing due diligence in avoiding even the risk of copyright infringement.

Paul.

On Tue, 30 Jul 2019 at 00:55, FeralChild64 notifications@github.com wrote:

And the IEC stack is not even fully compatible yet... I really don't know when I'll finish this. Report is here https://pastebin.com/d30er8BT. The longest one (21 bytes) is definitely my small jump-table in via_vector.s - a workaround for missing indirect JSR, it seems Commodore engineers had exactly the same idea. Should I shuffle the order to silence the tool?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/pull/27?email_source=notifications&email_token=AAFCOT7ZF4MM2AXMCPFZBZDQB4DXXA5CNFSM4IHNEJD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BCEYY#issuecomment-516039267, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFCOT5JYWDA242W6EXST2DQB4DXXANCNFSM4IHNEJDQ .

FeralChild64 commented 5 years ago

"Yes, do what you can to avoid similarities where possible" - well, I did it, but now I've found something in the "Mapping the C64": "There are 39 Kernal routines for which there are vectors in the jump table located at the top of the ROM (65409, $FF81). For ten of these routines, the jump table entry contains a machine language instruction to jump to the address pointed to by the RAM vector in this table". I guess our Kernal jumptable will have to be modified, we should replace 'jmp OPEN' with 'JMP (IOPEN)', etc. - otherwise vectors $31A-... will be useless, probably everyone just uses the Kernal jump table. But that's for the future, I don't want to do it now, I have already enough work with all the similarities we currently have. Some of them are... really hard to guess what these 3 bytes are really for.

gardners commented 5 years ago

For the jump table, you can keep this the same, we just have to indicate that it is a list of facts relied upon my a lot of software, and thus it has to be identical for many software packages to work. It is better if we can show existing software that depend on these as more solid proof.

For identifying the 3 bytes, have a disassembly of the C64 ROMs handy and look at the addresses it reports them occurring at, so that you can identify them. But, yes, it is annoying grunt work to go through them all. With practice it gets slightly less slow and annoying ...

FeralChild64 commented 5 years ago

All matches of > 3 bytes explained now. I don't want to change the jump table now, because it will surely spawn a bunch of other accidental similarities, and I have really enough of dealing with similarities for now - I'm going to do this within the next 'sprint'.

I thought the IEC code will be more similar - it isn't really, even the helper bit operation subroutines are clearly different. That's good, but... the code still needs some love to be more compatible with various devices.