question to SMT on Anril's sources

Hello, boo_boo > what is this? the same thing seems to be in itself - this is the “current time” of the emulated Spectrum - number of cycles from start In general, it’s good that there are already tangible results

Hello, All hi! I'm trying to port pieces of anril to Linux, I started with VG93... compile I managed to get it to work, but I can't get it to work yet. I think about the delays, everything else seems to be in itself, so the question is: the wd93cmd.cpp file contains the construction twice ┌─- CODE ─── comp.t_states + cpu.t └── CODE ─── What is this? I tried to shove all sorts of crap here (CPU cycle counter, frame counter, etc.), in in some cases, when trying to read a disk, a disc error occurred, in some -- reading error... :(

Hello,GriV stupid question

Hello SMT SMT> this is the “current time” of the emulated Spectrum - the number of clock cycles from start oooh, thanks! Now, with delays enabled, the drive polling time is similar to real... still disc error, however... hmm... after writing the sector read command to the command register, and during subsequent attempts to take something from the data register, the least significant bit of the status register (busy) permanently installed... :confused: Let's think about it :)

Hello, boo_boo did you take glyukalka or fuzz?

Hello SMT SMT> did you take the glitch or fuzz? glitch... I've been glitching all day, to no avail. however, I'm pretty approximate I have an idea about the work of VG, so it’s not surprising... Here is the log of the call to VG - maybe it shows at what stage the glitches started? ┌─- CODE ─── file /home/boo/!ZX/CM2DEMO.trd loaded in drive A I go to TRDOS: WD OUT(0xff,0x00) status = 10000000 WD OUT(0xff,0xff) status = 100 WD OUT(0x1f,0xd0) status = 10000100 32 times: { WD OUT(0xff,0xf7) status = 10000100 WD OUT(0xff,0xff) status = 10000100 } Doing CAT: WD OUT(0xff,0x3c) status = 10000100 WD OUT(0x1f,0x08) status = 101 /*restore*/ WD IN(0xff)=0xbf status = 100 /*INTRQ*/ WD IN(0x1f)=0x24 status = 100100 /*status*/ 2408 times { WD IN(0x1f)=0x26 status = 100110 /*pull the status*/ } WD OUT(0x1f,0x08) status = 100111 /*restore*/ WD IN(0xff)=0xbf status = 100100 /*INTRQ*/ WD OUT(0x7f,0x20) status = 100100 WD OUT(0x1f,0x18) status = 100111 /*track search*/ WD IN(0xff)=0xbf status = 100100 /*INTRQ*/ WD OUT(0x7f,0x01) status = 100000 WD OUT(0x1f,0x18) status = 100011 /*track search*/ WD IN(0xff)=0xbf status = 100000 /*INTRQ*/ WD IN(0x1f)=0x22 status = 100010 WD OUT(0x7f,0x00) status = 100000WD OUT(0x1f,0x18) status = 100011 /*поиск дорожки*/ WD IN(0xff)=0xbf status = 100000 /*INTRQ*/ WD IN(0x1f)=0x26 status = 100110 WD OUT(0xff,0x3c) status = 100110 WD IN(0x1f)=0x26 status = 100110 WD IN(0x3f)=0x00 status = 100110 WD OUT(0x7f,0x00) status = 100100 WD OUT(0x1f,0x18) status = 100111 /*поиск дорожки*/ WD IN(0xff)=0xbf status = 100100 /*INTRQ*/ WD OUT(0x1f,0xc0) status = 100111 /*чтение адреса*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x06 status = 1 WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x01 status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x63 status = 1 WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x9b status = 1 WD IN(0xff)=0xbf status = 0 /*INTRQ*/ WD OUT(0x3f,0x00) status = 0 /*уст. 0 дорожку*/ WD OUT(0xff,0x3c) status = 0 WD IN(0x1f)=0x00 status = 0 WD IN(0x3f)=0x00 status = 0WD OUT(0x7f,0x00) status = 0 WD OUT(0x1f,0x18) status = 1 /*track search*/ WD IN(0xff)=0xbf status = 100100 /*INTRQ*/ WD OUT(0x1f,0xc0) status = 100101 /*read address*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x09 status = 1 /*data*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x01 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x73 status = 1 /*data*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0xa5 status = 1 /*data*/ WD IN(0xff)=0xbf status = 0 /*INTRQ -- read address*/ WD OUT(0x3f,0x00) status = 0 /*set. 0 track*/ WD OUT(0xff,0x3c) status = 0 WD IN(0x3f)=0x00 status = 0 WD OUT(0x7f,0x00) status = 0 WD IN(0x3f)=0x00 status = 0 WD OUT(0x1f,0x18) status = 1 /*track search*/ WD IN(0xff)=0xbf status = 100100 /*INTRQ*/WD OUT(0x3f,0x00) status = 100100 /*set. 0 track*/ WD OUT(0x5f,0x09) status = 100100 /*set. 9 sector*/ WD OUT(0x1f,0x80) status = 100101 /*read sector*/ WD IN(0xff)=0x3f status = 1 30 times: { WD IN(0xff)=0x7f status = 11 /*DRQ*/ } about 100 pieces like this: { WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x7f status = 11 /*DRQ*/ WD IN(0x7f)=0x00 status = 1 /*data*/ WD IN(0xff)=0x3f status = 1 WD IN(0xff)=0x7f status = 11 /*DRQ*/ } WD IN(0xff)=0xbf status = 0 /*INTRQ -- counted the 9th sector*/ WD IN(0x1f)=0x00 status = 0 /*status -- like everything is ok*/ WD OUT(0xff,0x37) status = 0 / 15 times: {WD OUT(0xff,0x3f) status = 10000000 WD OUT(0xff,0x37) status = 10000000 } WD OUT(0xff,0x3f) status = 10000000 WD OUT(0xff,0x34) status = 10000000 15 times: { WD OUT(0xff,0x3c) status = 0 WD OUT(0xff,0x34) status = 0 } WD OUT(0xff,0x3c) status = 0 I get Disc Error └── CODE ─── UPD: hmmm, it looks like instead of the 9th sector, who knows what was considered case what error. But what the hell, did the checksum match? :confused:

Hello,GriV ooooh, that's right, damn it, I'm an idiot - solid zeros are readable ^____^ my dislike for global variables let me down - shoving them into classes, not paid attention to the design memset(this, 0, sizeof(FDD)); :p in short, victory, it WORKS! we still need to check different bootloaders, etc., etc., but In general, we can say that the alpha version of the port of the VG93 emulation module from UnrealSpeccy for Linux is ready! :)

Hello,GriV SMT is a professional! It’s immediately obvious, because “only a professional programmer can explain it easier, why can’t you write something with which to write” :) I think that’s how it was written :) Boo boo - well done! Give the emulsion for Linux... I think there is a queue of people interested. I, By the way, I don’t mind either.

Hello SMT SMT> stupid question I don’t see anything stupid at all, maybe you can still answer?

Hello SMT SMT> GriV, too general question. it’s the same as telling “from which SMT> considerations" the TV shows the picture. detailed answer now SMT> I can’t give Okay, I'll wait, but I really need this answer.

Hello, boo_boo GriV, too general question. it’s the same as saying “for what reasons” the TV shows the picture. I can’t give a detailed answer right now boo, if I guess what’s wrong, I’ll write

Hello SMT It looks like Spectrum found and read the data. probably a bug in the bootloader TRD files that generated incorrect CRCs for sectors (you can also download immediately upload in UDI format, and then compare with the Windows version). however CRC for address marks are formed correctly (63.9B for the 6th sector)

Hello SMT or rather, the matter is not in the CRC (it seems to be correct), but in the fact that Spectrum did not find the code #10 in the desired location in the system sector of the disk. or TRD like this (with pure 9th disc error sector - correct behavior), or the data does not reach processor from the disk image. check the TRD bootloader anyway

Hello,GriV Gri> but I really need this answer Why is it “very”? Now I’m going to say a lot of banalities, please don’t read the smart ones ^_^ so, the sound blaster plays the sound not in a continuous stream, but in small ones buffers consisting of samples, for convenience (for me) time equal to 1 frame (1/50 sec.) we have at the input switching bit 4 in port #FE at some moments during emulated frame, and at the output we want a buffer with sound samples. if frequency digitization is 48khz, then the size of the frame-length buffer is 48000/50=960 samples. Now, the task is how to fill this buffer suppose that at the beginning of the frame (pentagon, 71680 clock cycles per frame) the state #FE was 0. and after 5000 cycles 1 was output there, then after 5000 cycles - 0 again, etc. (700 hertz tone). then obviously you need to fill the beginning of the buffer with 0 to sample number 66 (5000/71680*960 - this is the proportion), then from sample 67 to sample 133 (second pin at clock 10000, corresponding sample number 10000/71680*960) some non-zero value depending on the set speaker volume and so on until the end of the buffer when the buffer is ready, it is queued for playback on the sound card (so Thus, at the moment, almost all emulators use buffers from past and even, more likely, the day before or pose-pose-past frames,but you have to put up with it in exchange for other delights of emulators) in reality we see that due to rounding errors when calculating the position level change sample, the distances between edges in the buffer are not the same, so (and for a couple of other reasons) spurious frequencies arise (so-called aliasing). what is this this and how to deal with them is written in any more or less self-respecting textbook on DSP, it’s better for me not to say. I recommend http://dsp-book.narod.ru Well, if you’re so lazy to open the textbook, maybe someday I’ll write down a popular one lecture like this

Hello, boo_boo boo> in short, victory, it WORKS! You also need to check different bootloaders, etc. boo> and so on, but in general we can say that the alpha version of the module port boo> VG93 emulation from UnrealSpeccy for Linux is ready! :) cool! :eek: congratulations! I hope this miracle can be compiled under FreeBSD? (in the future :rolleyes: )

Hello, boo_boo by the way, I made a mistake above, not 700hz, but 350 in the example

Hello, breeze bre> cool! :eek: congratulations! I hope this miracle can be compiled bre> under FreeBSD? (in the future :rolleyes: ) thank you ;) The VG93 emulator itself, torn from the US, can be assembled under anything - there’s only Standard C-libraries are used. ZX emulsion on which I experiment now it’s a twisted glitch, if an ordinary glitch plows under frey, then with there shouldn't be any problems with this farm :cool:

Hello SMT Okay, I understand, I’m just interested in antialiasing. Here's the thing - for example, the same dizzy displays on the start screen (the original version is meant) quite a decent music - if just poking the beeping state into the audio range, then nothing good will come of it - proto because in the specified period of time - even for 48 kHz it turns out about 73 beats - he (beep) changes his state and sometimes even more than once and of course That's where the question comes from. On a real speck it’s like - there is a trigger at the output of the beep and SPK and there is its internal capacity which leads to non-instantaneous when a trigger is triggered - for example, within a few microseconds it changes its level to the opposite (non-rectangular signal). Those. in any case there is non-instantaneous transition to the opposite state, and then I studied the diagrams, received by US - and it turns out the same way - that the beep signal does not change instantly rectangular - and after a certain number of counts - about 1-2 samples of the output audio range (48 kHz is still the same). That's where the question comes from - Where does this “slope” of the curve of changing the state of the beep come from? This is exactly his does it provide antialiasing?

Hello,GriV yes