| |
mstram
Account closed
Registered: Dec 2013
Posts: 112 |
Release id #145523 : jsSID-0.9.1
No discussion on this ?
Yes I see the comments, but this is freaking INCREDIBLE !
Congrats Mihály !
Though the absurd speed of today's p.c's obviously helps to make it possible, I'm in awe of Hermit and all of the other programmers who have worked on SID emulation.
The next thing I'd like to see, and I'm trying to possibly figure it out now, is a browser based "mini-editor" or "SID playground".
I.e. a (very) stripped down VICE / basic interpreter that only understands POKE, and maybe FOR, NEXT, and variables / arrays.
I'm looking through the JsSid source now to see how / if I can play / send single notes / or trigger the SID registers.
I see there is some kind of minimal CPU simulation there.
Mike |
|
... 6 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
...and "ANC #immediate" as well. (Sorry for spamming. :) ) |
| |
Digger
Registered: Mar 2005
Posts: 421 |
Feel free to fork the repo (https://github.com/hermitsoft/jsSID), implement what you need and make a pull request :-)
I am currently working on the cleaning up the docs styling in my own fork (https://github.com/og2t/jsSID), had no time last week but expect updates soon. |
| |
mankeli
Registered: Oct 2010
Posts: 110 |
Please integrate this to CSDB! |
| |
Hermit
Registered: May 2008
Posts: 208 |
As jsSID is not a complete environment (it's not aimed for that) I think it needs quite some addition to be useful for complete CSDB/HVSC integration to play ALL tunes, but that means it can grow twice as big and eat more CPU in the end...
As Digger says, feel free to implement the illegal opcodes, that would increase the CPU code, but it will still be considerably small I think...
Personally I don't like the idea of using illegal opcodes in SID music, because that can fail on many emulators/players which are targeted for slow systems and lack illegals/etc. by definition. For 1raster tracker I had a reason to use LAX, but that's another story... For normal music players I don't think those few cycles are worth the risk of non-working tunes/demos on some lower end systems...
(I saw the SBX #7 in players to advance SID-channels, but TXA;SBC#7;TAX would only be 3*(2+2) = 12 cycles more if we take all the 3 channels...)
@Bakakaj (what a funny-sounding name for a tune) seems to use an own 'RealSID' player (player-address is 0 in SID-header), and who knows what it does inside... Only a real VIC and CIA and IRQ emulation can play all of these SIDs...but as I said several times, I have no plans for these things...maybe someone else picks it up where I left it if there's enough interest to have a full jsSID implementation... |
| |
mstram
Account closed
Registered: Dec 2013
Posts: 112 |
Hurray !
I have figured out the primary "playground" step, i.e being able to "poke / peek" to the SID.
1) I added two functions to the jsSID function / class / object:
"peek"
this.getmem = function(addr) { return memory[addr].toString(16) }
"poke"
this.setmem = function(addr,val) {memory[addr] = val; }
2) By using the "poke" (setmem) function, I altered the loaded SID file by changing the initaddr, and playaddr contents :
(pseudo code)
initaddr jmp initaddr ; usually 0x1000
playaddr jmp initaddr ; usually 0x1003
After "patching" the loaded SID, the tune of course halts playing the last note.
At that point I can use further calls to "poke" (setmem) to alter the SID.
I added simple input boxes to accept the addr / data.
I'll "pretty" it up, by adding a select input for the SID regs, and other stuff.
Next I'm going to create a "dummy" SID file, that's already "patched", so that it can just be selected from the play list, and the "manual patching" won't be necessary. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Hermit: You need to set carry to a known state as well if using TXA:SBC:TAX. Anyway, I totally respect the design choice for jsSID not to support all kinds of possible stuff that's very reasonable but I strongly disagree on making "compromise coding" an ideal for C64 stuff. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Oh yes. I usually place code in a way that Carry-flag is set already as a side-effect of a CMP or SBC, but sometimes of course it's unavoidable to set carry with SEC/CLC. Isn't it required for SBX? Then I understand it's attracting for coders...
My common sense tells me: one can never now what the user uses, maybe a special 6502 variant in a custom hardware or an FPGA implementation that aren't compatible with all the 'allowed' illegal opcodes...
Well, demos are all about undocumented behaviour of C64 chips, for that using illegal opcodes is not a big issue, one won't be surprised if something doesn't work as on real C64. The worst that happens is that a demo can't be watched in its full potential.
But when it's for example a music collection, or even more sensitive stuff like a production tool, users who aren't clearly notified about the program containing illegal opcodes, can face unpleasant moments of hidden errors when a program operates erroneously due to misinterpreted illegal opcodes. (Sure, he/she took the risk on the emulator side, but he/she can't check efficiently in monitor if the binary program has opcodes with a potential risk or not. If source code emphasizes that illegals are used, the case gets easier... Fortunately I shared the source-code for 1raster tracker, but I didn't make it apparent in the help text that a LAX is used, so I made this mistake already with 1raster-tracker. This is the only illegal opcode I've ever used though, and I had a strong reason to do so to better fit in 1 rasterline, and I still kinda regret it...)
I wouldn't call it 'compromise coding' to avoid illegal instructions if you mean that above. VIC and SID tricks usually don't affect program flow much, but CPU can cause unpredictable results even for the smallest differences in code interpretation... Illegals can save some cycles and bytes for the program, but can cause hours of headache for users due to lost workfiles in the worst case (e.g. if illegal opcode is in the disk saver routine, or even if a seldom used effect in a music player occasionally causes program freeze due to illegal opcodes that the user don't know about)...
I don't want to tell anyone not to use illegal opcodes, but indicating in the release it's a stock C64 program (and may not run well in some emulators/players) is a must IMO, from user point of view. On the other hand, this information should be preserved throughout the life and incarnations of a program/tune (which is usually not guaranteed). (If SID header 'targeted for Real C64' RealSID information switch refers to the fact illegals may be contained, that's already done for SID file format, but I'm afraid that there are many RealSID tunes that has no illegal opcodes and so they shouldn't be rejected by players that don't support illegals...) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Hehe.. well.. I see what point of view you're coming from of course, but let's just agree to disagree. :) From my point of view anything that works on stock C64s is 100% fine however it may be constructed.
No need to set carry to a known state for SBX. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Quote:From my point of view anything that works on stock C64s is 100% fine however it may be constructed.
this :) the discussion reminds me of the "emulator id" stuff that was put into C64 emulators in the early 90s - thank god we got rid of this nonsense by now :=P
Quote:No need to set carry to a known state for SBX.
yup. they key here is that its a combination of CMP and DEX (and not SBC/DEX as one would think by the mnemonic) |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Sbx, anc, lax, arr, all fine & legal opcodes to me. My player is meant for c64 with a Sid. I see no reason to stick to a programming dogma that excludes things from Sid/CPU emulation. Great work nevertheless, Hermit. |
| Previous - 1 | 2 - Next |
