[CSDb] - User Forums - Release id #145523 : jsSID-0.9.1

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #145523 : jsSID-0.9.1

2016-03-07 05:40

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

... 10 posts hidden. Click here to view all posts....

2016-03-09 04:48

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.

2016-03-09 08:04

Frantic

Registered: Mar 2003
Posts: 1648

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.

2016-03-09 12:22

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...)

2016-03-09 18:22

Frantic

Registered: Mar 2003
Posts: 1648

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.

2016-03-09 18:32

chatGPZ

Registered: Dec 2001
Posts: 11390

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)

2016-03-10 09:17

Hein

Registered: Apr 2004
Posts: 954

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

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

E$G/HF ⭐ 7
TheRyk/MYD!
Marco/DDM
kbs/Pht/Lxt
Ghost/Quantum
anonym/padua
Tweety
Guests online: 116

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 The Demo Coder  (9.6)
8 Comaland 100%  (9.6)
9 What Is The Matrix 2  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 Morph  (9.5)
7 Dawnfall V1.1  (9.5)
8 Libertongo  (9.5)
9 Katzen-Video.mp4  (9.5)
10 Onscreen 5k  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Triad  (9.3)
5 Fairlight  (9.3)

Top Musicians

1 Mutetus  (9.7)
2 Jeroen Tel  (9.6)
3 Rob Hubbard  (9.6)
4 Linus  (9.6)
5 Jammer  (9.6)

Page generated in: 0.068 sec.