Author Topic: Media Player 128 Beta (Read 2742 times)

Wagner · « **Reply #25 on:** December 18, 2011, 01:55 AM »

Quote

The CPU in the 1581 (and 1571) runs at 2MHz, does anyone know what speed the CPU in the CMD-HD runs at?

It's been years, but I'm pretty sure the CMD-HD runs at 2MHz.

Wagner · « **Reply #26 on:** December 18, 2011, 03:23 AM »

Quote

What I don't understand is that because this is using +/- 1 filter, and my code is using +/- 1 filter, why the mouse will drift in MP128 but not with this code...

You can fool some of the mice all of the time, and all of the mice some of the time, but you can not fool all of the mice all of the time.

Hydrophilic · « **Reply #27 on:** December 20, 2011, 12:21 PM »

Considering we're both doing the same basic task, but mine has problems, there had to be a bug in my code. After a 3rd look, I still couldn't see it (looking at the source code or stepping through the object code with VICE).

So in the ML monitor I patched my own code to add noise to pot values. I thought it was kind of funny to use the SID's own noise generator to add noise to the noise-free pot readings. And bang -- the mouse starts drifting accross the screen just like tokra said.

When calculating absolute value of +/- delta, the value gets negated if initially negative and then tests for +1. When the value is initially positive, the code was suppose to branch past the negation and test for +1. However, I branched beyond the +1 test. So only half the values were getting filtered, causing a bias to accumulate and the mouse to drift. Well that was an extremely easy fix (change the branch) once I was able to reproduce the bug.

As soon as I get the REU buffer code tweaked, I'll upload the updated executibles and source.

Hydrophilic · « **Reply #28 on:** January 01, 2012, 04:13 PM »

I've uploaded the code with small patches as discussed previously. To summarize:

Fixed mouse noise filter
Added option to pause after loading REU
Added option to specify data rate of your device

The last one is because it seems the CMD-HD is slower than 1581, and it is also useful because uIEC is faster than 1581. It defaults to 1581 speed based on your machine (NTSC or PAL). So if you have a faster device (uIEC) or slower (CMD-HD), then try changing the data rate if you have problems playing an audio or video file. Also you can lie, and give a really low data rate if you want to disable playing from the fast serial bus and force the use of an REU.

The 1581/NTSC is a bit slower for playing videos. Previously I said the videos will not play with NTSC/1581, but I added another video to the 1581 download. It has a slightly slower frame rate but at least NTSC users with only a 1581 can watch a video. Or rather a video clip, as a full video won't fit on a 1581 disk. Of course NTSC users with an REU or uIEC can also watch the faster videos.

Also, I noticed there were about 3x as many downloads of the image from the Britney Spears video as compared to the Nickleback video... so I replaced the REU-only video in the HD-download with Britney and enlarged the frame a bit... Attached are 4 images from that video... Happy New Year!

tokra · « **Reply #29 on:** January 02, 2012, 05:06 AM »

Just tried this. Mouse pointer is rock steady, UIEC loads like a charm. Great :-) However I have problem playing the REU-video included. I can see the REU loading, and when it's finished there is the pause for the keypress. However when I press space the screen just goes "widescreen" but neither video nor audio play. It stays like that until I press RUN/STOP which returns me to the menu. Strange. I think i got a REU-video playing with the older version, did you change anything? For example: The REU can only be loaded in SLOW-mode. I think I saw some "FAST"-commands browsing the code

Hydrophilic · « **Reply #30 on:** January 02, 2012, 05:57 PM »

Glad to hear the mouse works correctly now as I could only emulate the noise and wasn't sure if I really fixed it...

I didn't change anything in the audio or video codecs, only the file codec. Now it calculates the bandwidth (data rate) from the file header. If this calculation is more than the data rate set on the Config->Loader screen then it forces buffering by the REU, otherwise it tries to stream the file from fast serial (if available). The other change was in the REU loader code to read the TOD before loading then compare after loading... if it takes longer than the timeout on Config->Loader then it gives the READY TO PLAY message.

So it seems it loaded the file and gave you the message correctly, then you press SPACE/FIRE/CLICK to start playback, then it tries to play (text screen switches to bitmap), but nothing happens... until you press STOP to return to the menu.

Well that tells me that CPU hasn't gone totally nuts because you are able to regain control. Umm, just an idea, but the SPACE is also used to pause / resume the video. It could be (cross your fingers) that when you press SPACE to start playback, the keyboard bounce is not properly handled and it goes into pause mode. This should be easy to test: when the screen goes black (switch to bitmap mode), try pressing SPACE/FIRE again. If we're lucky, that is the problem and the video will un-pause and resume playback.

Hopefully it is just the SPACEBAR not being debounced properly... I noticed in VICE there is no problem, but on my real machine the RETURN key is often read twice by accident (not using my code, but relying on BASIC / KERNAL !)... like on the configuration screen where you have to type a value and press RETURN, but the RETURN is also used to trigger the OK button. So pressing RETURN once to enter a value will sometimes both enter the value and activate the OK button... that is I have to lightly press RETURN on my real machine or the BASIC programs acts like two seperate RETURNs have been entered...

Did you try all 3 videos? Did any of them play... when you say it works great from uIEC, does that mean the 2 low-rate videos work but the 1 high-rate one fails?

The reason I ask is that problem may be due to the way the software expects the REU to work. I don't own one, and VICE is not 100% accurate. I did notice in VICE that things work fine if the REU emulation is set to be 512K or less (like a real unmodified REU) or also if the emulation was set to 4MB or larger (something a real REU can not do, but of course devices like 1541 Ultimate can).

Specifically, it seems that an REU emulation of 1MB ~ 2MB (which would correspond to a hacked CBM unit) will fail because of the 'bank' register of the REU ($df06). What happens is the 'bank' register will roll-over to zero if it tries to increment past 7. That is, values 8+ will not be generated internally by the REU (that is, address values above 512k). Which seems reasonable for a hacked CBM unit. Of course I do not own a hacked unit because I don't have one at all, so I am not sure if this is a 'bug' with the emulation or a 'feature' of hacked REUs.

Long story short, it could be that this bug/feature of hacked REUs is also present in 1541 Ultimate but not emulated in VICE. That is, the 'bank' register seems to work 'correctly' for REU setting of 4MB~16MB in VICE but I can't be sure because I don't own a 1541 Ultimate either. I plan on getting one so this can be solved definatively in the future, but don't hold your breath!

If somebody with a genuine unhacked REU (preferably a 1750) could report if the player works or fails, that would be very helpful.
-------

Oh, you are brave enough to look at the code! I tried to keep it simple and modular, but so many things come into consideration it has turned into a bit of a mess. It's not total spaghetti code yet, but it's not a thing of simplicity and beauty either!

It uses FAST mode as much as possible, but care has been taken to be sure it is used correctly. For example, it can run 2MHz all the time for fast-serial, but calling into JiffyDOS/KERNAL will slow down to 1MHz momentarily. This is also the case for the REU loader... most of the loader will run at 2MHz but it slows down to 1MHz to read/store data to the REU. For example

Code: [Select]

sty $d030 ;1MHz for REU access
sta $df01 ;execute REU command
stx $d030 ;resume 2MHz for CPU

Another important thing is the VIC and REU both use the same DMA bank setting from the MMU. So care has to be taken when playing a video that loading into bank 0 does not occur when the VIC is displaying data in bank 1. If this were done incorrectly, then either data would load to the wrong bank (trashing most every BASIC variable) or else the video would be corrupted because the VIC would be displaying 'junk' from bank 0 (the BASIC or ML program).

Anyway, sorry the REU video is not working for you, as the slightly larger image and higher frame rate is much nicer to watch compared to the fast-serial version. Hopefully this will get sorted out, as this is new code, and much potential remains. For example, 2-bit audio is crap that was invented as a low-bandwidth solution for the serial bus. But with an REU, 4-bit audio should be possible with the video. Also the fast-serial video limits itself to 4 colors for the entire bitmap, but the with the speed of the REU, it should be easy to use all 16 colors...

Thanks again for the feedback!

tokra · « **Reply #31 on:** January 02, 2012, 10:20 PM »

Ok, I took your suggestion, pressing the spacebar again and this produced audio-noise, which I could togge on/off with the spacebar. So obviously the player reacted to the spacebar, but no video or sensible audio was playing. Then I tried to set my 1541U2 to 512K REU instead of the 16 MB I had it set to before. And that fixed the problem! I was able to watch Britney sing and dance with a much better framerate than before through FastSerial. The video stopped after about 1 minute (on Britneys scream), I suppose that's the way you encoded it?

Anyway, no need to get out my old 1750 REU since it worked with the Ultimate and 512K-setting. I'd have to do some reading on how memory larger then 512K or 2 MB can be accessed since the Nuvie-player shows it can be done. Even GEOS can handle expansions up to 2 MB.

Hydrophilic · « **Reply #32 on:** January 03, 2012, 02:30 AM »

Tokra, your awesome! That pretty much confirms (in my mind, call me crazy) the problem is with the REU bank roll-over.

The video should play all the way through, but since you set your Ultimate to 512K mode, then MP128 only loaded the first 512K, and so the video only played half-way. See, I told you she is much better with a larger size and higher frame rate

More important, is the bank roll-over bug does not appear until a size larger than 512K is used. It is strange that this bug/feature only appears in VICE for an REU between 1MB and 2MB. I mean it does not happen with 4MB or 16MB... VICE works fine with both Nuvie Player and MP128 in that case...

I guess my optimistic method is more than the VICE team could emulate. Optimistic in the sense that my code expects the REU to actually auto-increment its internal address when you set it it to auto-increment. Imagine that... how I could I be so foolish

So I'm thinking that auto-increment actually morphs into auto-reset when the address attempts to cross the 512K boundry. However directly slamming a value into the bank register (as opposed to the theoretical auto-increment) seems to beat some sense into the device... Anyway, if all this theory is correct, it should be conceptually easy to change the software. But in practice it will mean some fundamental changes as the CPU was relying on the REU to calculate the next address.

Which is to say it should work if I don't let the REU do the address math. Just goes to show if you want it done right, ya gotta do it yourself. I mean really, I think the VDC auto-increment feature has developed a bit of a bad wrap (I enjoy criticising it), and yet I haven't learned anything from that... CBM auto-increment = trouble. Really simple.

Thanks again!

tokra · « **Reply #33 on:** January 03, 2012, 04:03 AM »

I've searched around for REU-documentation and the best I could find was here: http://codebase64.org/doku.php?id=base:thirdparty#ram_expansion_unit_reu
Check the "Technical Reference" by Wolfgang Moser. It says:

"1750 expanded to 1MiB or 2MiB: The REU counter wrap around 512kiB does not wrap from one of the extended 512kiB banks into another one. Exchanging banks can only be done by writing into register 0xDF06, but is not automatically done through wrap-around"

To be fair, Commodore never planned to expand more than 512K back then, so even increasing up to 2 MB is really just a hack. The 1541 Ultimate 16 MB mode is just maxing the bank counter out completely, but I guess due to compatiblity Gideon kept the "not automatically wrap-around" bug/feature in there though technically he didn't need to.

RobertB · « **Reply #34 on:** January 03, 2012, 11:00 AM »

Quote from: Hydrophilic on January 02, 2012, 05:57 PM

The reason I ask is that problem may be due to the way the software expects the REU to work. I don't own one...

Do you want to borrow one for awhile?

Back in California but not back home,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

Mathias Roslund · « **Reply #35 on:** January 03, 2012, 09:38 PM »

Quote from: tokra on January 03, 2012, 04:03 AM

To be fair, Commodore never planned to expand more than 512K back then, so even increasing up to 2 MB is really just a hack. The 1541 Ultimate 16 MB mode is just maxing the bank counter out completely, but I guess due to compatiblity Gideon kept the "not automatically wrap-around" bug/feature in there though technically he didn't need to.

He probably kept the bug/feature to stay compatible with the expanded REUs and CMD's 2MB REU, which has the same issue as it's using the original REU chip.

Hydrophilic · « **Reply #36 on:** January 04, 2012, 08:42 AM »

Thanks for the link to the document, tokra. I was pretty sure it was the bank wrapping based on VICE 1 and 2 MB setting and your last report, but that confirms it.

I was just having fun blaming Commodore. I expected the player to have problems with a 1750 that was hacked to 1MB or 2MB, because obviously Commodore hadn't designed the units to work at that size. The suprise is that me and the VICE team appearantly had the same misconception -- that a device designed to handle 16MB would actually work correctly. But unfortunately some such devices, the 1541U2 at least, retains the wrap bug.

Thanks for the offer RobertB, but now the problem seems confirmed, I shouldn't need to borrow any hardware. It's just a matter of time for me to re-write the code. It won't be this week, but I should get to it before February.

So anyway, the REU stuff should work for an unhacked Commodore unit, and for the 1541U2 if you set it to 1750 combatibility mode (512 kiB size). In other words the full potential shows only in VICE, and real hardware is limited to 512 kiB until I can update the code.

maraud · « **Reply #37 on:** January 06, 2012, 01:32 PM »

Is it possible to add a config option to tell your app to ignore what "it thinks" it is talking to and just run the kernel mode and see what happens? I seem to have gotten this to "kinda" work when loading a 7,000 block file from my CMD to the REU in the 1541U2 via parallel. It took about 3 minutes to load the 1.7 meg file to REU and play it. I'd love to "force" it to try and buffer via kernel routines.

Hydrophilic · « **Reply #38 on:** January 06, 2012, 11:26 PM »

You can force it to ignore fast-serial and use the REU by changing the Config->Loader datarate to a really low value, like 4500 By/s(which is the minimum). You can also force it to use fast-serial and ignore the REU by changing the datarate to a really high value, like 15000 By/s.

However, it can not load directly from the KERNAL (an REU is required). This is becausing calling into the KERNAL is way too slow for real-time playback of 8-bit audio or videos. It might work for 4-bit audio. I'll have to think about that...

Okay I thought about it and won't work because the KERNAL is flawed. It always calls this routine to disable interrupts and change the CPU speed, disable sprites, etc. when you call it. And upon return it calls a complementary routine to enable interrupts and restore sprites and CPU speed etc. Well there is a flag you can set that will prevent KERNAL from changing CPU speed and such, but the flaw is it ALWAYS enables interrupts before return. The KERNAL interrupt routines are too slow to begin with, and trying to intercept the KERNAL IRQ using bank switching would make it even slower.

In other words, MP128 is only possible because the CPU can read data quickly from the fast-serial bus (with a simple LDA $DC0C) or from the REU (with a simple STA $DE01). Calling a subroutine (in case of the KERNAL, a cross-bank subroutine) takes too long for a stock CPU. Could be possible with a SuperCPU...

As an example that I'm not just making excuses, you said it took 3 minutes to load the 1.7 meg file into the REU with a parallel cable. I assume this is one of the videos or a full 8-bit audio file. In which case the playback time should be about 3.5 minutes. So it may sound like the CPU has 0.5 minutes to spare... but the CPU is doing absolutely nothing else while loading the REU (well, it flashes the screen once every 4096 bytes). When you actually play an audio file, the CPU has to interrcept CIA timer interrupts and feed the SID audio samples in addition to reading data. So hopefully you could see how this would take 4 or 5 minutes if you tried to use the KERNAL directly. And that is just for audio-only. In the case of video it is worse because the CPU must spend a lot of time at only 1MHz and looses even more cycles due to VIC bad lines. So I would imagine it would take 5 or 6 minutes using the KERNAL in that case. I hope you can see that it would take much longer than the available 3.5 minute play time.

maraud · « **Reply #39 on:** January 07, 2012, 02:18 AM »

I get your point completely. The interesting news is that I disconnected the serial connection from my CMD and used parallel only. For some reason it no longer sees it as JiffyDOS but as a kernel device. So that, with the REU, loaded the file in < 2 min. It flashed about 1.5 times per second. Theoretically the parallel should be able to deliver data as fast as the REU (assuming the disk/SSD device) can move data fast enough.

Hydrophilic · « **Reply #40 on:** January 07, 2012, 05:01 AM »

That is interesting. It is like your KERNAL was using the serial bus the first time, but obviously it had to use the parallel cable if you disconnect the serial!

And less than 2 minutes is a really fast load time. It should be possible to write routines to directly read from the parallel cable, something like LDA $DD01, I imagine. In which case it could work without need of REU. I don't have the hardware to be able to write that code myself. I don't know if there's anyway in VICE to emulate the parallel cable for me to even try.

I'll be doing good to get the REU wrap bug patched up this month, so it would be a quite a while before I could start any code optimized for the pararallel cable. But if anybody good at assembly language wants to give it a try, I could give pointers on the source files that would need to be added and changed.

Thanks for the feedback, maraud (very interesting).... say, this is all on your CMD-HD right? I was wondering if you had a chance to try it with an FD-2000 or FD-4000. I always imagined it would work like using a C1581, but haven't heard any reports so was curious.

Edit
A bit off topic, but I just noticed that the REU-wrap-bug for 16MB units has appeared in VICE 2.3 ... which is to say it acts like the 1541 Ultimate II as reported by tokra. There is no wrap bug in VICE 2.1 except for 1MB and 2MB size REU which, unfortunately, is the version I was testing when I wrote the new REU routines. Hopefully I'll get a wrap-bug-enabled (i.e. fixed) version up next weekend (around January 21).

gsteemso · « **Reply #41 on:** January 17, 2012, 09:20 AM »

I had an interesting thought which I’d value everyone's opinion of. We know that full-colour images (up to a couple of hundred possible hues) are possible with the VIC-II and by extension the VIC-IIe, through sprite trickery and the blurriness & colour artefacts of a CRT. (I believe the technique is called Super-HIFLI?) Logically, it should be possible to do that fast enough to get full-colour, full-motion video (25/30 fps, PAL/NTSC), provided the video window was very small rather than full-screen. Something similar was done in early versions of QuickTime for Mac OS and Windows — they couldn’t move the data fast enough for full-screen video, so they shrank the window size until the hardware could keep up. That’s why the maze puzzle in the original Myst (remember that?) had you looking out at the tracks through such a tiny porthole.

Hydrophilic has worked miracles getting several frames per second in full-screen video. How big of a _full-motion_ video can be achieved by using similar techniques, but in a smaller area on screen? It seems to me that once such a thing was achieved at all, it would just be a question of how big the window size could be pushed. For videos where having more colours than the current version can show is essential, a different codec that produces a smaller window would be used.

I’m very excited about this idea, and if I had the power supply problem sorted out for my 128 setup, I’d dive straight into trying the idea for myself. As matters stand, I will have to hope someone else gives it a go and gets back to us here.

RobertB · « **Reply #42 on:** January 17, 2012, 12:48 PM »

Quote from: gsteemso on January 17, 2012, 09:20 AM

...for Mac OS and Windows — they couldn’t move the data fast enough for full-screen video, so they shrank the window size until the hardware could keep up. That’s why the maze puzzle in the original Myst (remember that?) had you looking out at the tracks through such a tiny porthole.

Certain games used that same technique with Amiga computers.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org

Hydrophilic · « **Reply #43 on:** January 17, 2012, 03:01 PM »

Thanks for the positive review of my work, gsteemso. While the wide-screen (16:9) is almost full screen (38 out of 40 characters wide), the standard-screen (4:3) is nowhere near full screen... typically only 17 out of 25 characters tall. One thing you can do now is specify a smaller screen size when you create a video. In fact, that is what I should have done with the NTSC-cripled videos I just put up (such as the aqua-scale, Power of Goodbye).

You see, on an NTSC machine you need a realy fast fast-serial device like uIEC to play the 'normal' videos, but RobertB was saying he would be using a 1581 or CMD-HD (or possibly uIEC without fast-serial upgrade, if I understood correctly) so I reduced the data-rate without changing the image size. Well you can guess this came at the cost of frame rate, which decreased about 10% (the peak went from 3.67 fps down to 3.5 fps and the average went from 2.65 down to 2.42). Since it won't be until next month before he shows it off, I might actually do that (make the video a bit smaller = faster).

Of course making the video smaller will improve only the frame rate but not the image quality. Like gsteemso said, somebody would need to write a codec to implement something better like IFLI. I have a bunch of ideas to improve the video quality in both terms of frame rate and image quality, but haven't found the time to work on them this past year nor will I get to it anytime soon this year.

I think gsteemso has the right idea, to start with a very small full-rate video and then push the limits. According to rough calculations, the current codec should be able to handle 462 frames per second if the video were only 1 char in size

. Of course the VIC can't output that many frames per second, and I doubt your monitor could handle it either. Another rough calculation shows that with a size of 10 chars wide by 6 chars tall (80x48 hi-res pixels) you might get 'full-rate' video of about 25 frames per second. Again this is using standard bitmap mode, who knows what you would need for something advanced like IFLI.

The above calculations are based on streaming the file from fast-serial. If you have the patience to load up an REU instead of streaming the file in real time, then you might get around 25 fps if you used a size of 14 x 9 chars (112x72 hi-res pixels). I think that is really small considering normal bitmap mode and the speed of the REU, but the bottleneck is created by CPU time spent playing digital audio (one interrupt every 2 rasters).

In theory the encoder and the player should be able to play a video without any audio. But in practice I haven't implemented that feature (silent video) so would fail if you tried it. That's a good idea for the next release, whenever that may be.

Anyway, thanks for the ideas. Keep 'em coming!

RobertB · « **Reply #44 on:** January 17, 2012, 06:22 PM »

Quote from: Hydrophilic on January 17, 2012, 03:01 PM

...RobertB was saying he would be using a 1581 or CMD-HD (or possibly uIEC without fast-serial upgrade, if I understood correctly)...

Correct. Maybe I should get off my duff and update the SD2IEC and the uIEC with the latest firmware.

Quote

Since it won't be until next month before he shows it off, I might actually do that (make the video a bit smaller = faster).

Yup, the next FCUG meeting will be on Feb. 19.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

Hydrophilic · « **Reply #45 on:** February 04, 2012, 10:01 PM »

Don't worry too much about upgrading uIEC. It does elimante need for REU, but otherwise the difference between 'normal' video and reduced-for-NTSC is very minimal (less than 10%). You would probably have a hard time telling the difference unless you watched both versions one after the other. Also, MP128 is confirmed working on (upgraded) uIEC for both NTSC and PAL systems. So it would be interesting to hear how it works with other hardware. Also if you have an REU, it doesn't matter how fast your storage device is.

As promised, I've updated the code to deal with the REU bank-wrap bug. I think the VICE emulation of the bug/feature is wrong. In VICE, once the REU bank goes past 7, my code has to constantly update the REU bank for every fetch/stash operation (even if it doesn't cross banks). As I understand the hardware for hacked REUs and the CMD-REU, the extra memory is handled seperately from REU controller... so I don't see how that extra hardware would 'know' to 'reset' the banks like happens in VICE.

So for example, if reading from bank 7 then going to bank 8, the extra hardware would not know, so of course the code needs to update the bank register. But, once set to bank 8, further updates should not be needed (until changing to another bank). Well, this is how I imagine it would work in real hardware, and it is NOT how it works in VICE. In VICE, once in bank 8 (or any bank above 7), the bank register has to be manually set for EVERY stash/fetch operation.

So the software is now a bit slower than before (for example, maximum 8-bit audio rate decreased from 15.5 to 14.4 kHz). The updated code should work with real hardware, even if VICE is wrong. I suspect VICE might be trying to emulate 1541 Ultimate or similar which of course WOULD know if there was a change to ANY registers.

Details

The bug fix required changes for loading the REU (which was simple because it always loads 4kiByte chunks) and also for extraction/playback (which was rather complicated). In fact the playback required 7 changes:

For every data packet, calculate the end address inside the REU and test for bank wrap
If the end address wraps, a flag is set and a check is made to see if the packet needs to be split
If the packet needs to split, the length of the first part (current bank) needs to be calculated
For every fetch/stash operation, the REU bank register is manually set
After every packet (half) is fetched, the wrap flag is checked
If the wrap flag is set, the new REU bank is calculated and the split flag is checked
If the packet is split, the second part (new bank) is fetched from the REU

That may seem overly complicated, but I tried simpler ways first and they failed. This version works in VICE 2.3 (which seems to do better REU bug emulation) and also works in VICE 2.1 (which does not have REU bug). I imagine it will work with real hardware too. So if anybody would care to test this with an expanded 2MB REU or 1541 Ultimate and report results, it would be appreciated. Here is the HD download, here is the 1581 download, and here is the 1541/71 download. Oh yeah, here is the source.

If your reading this RobertB, I downloaded the best versions of "Harden My Heart" and "Walking on Ice" by Quarterflash that I could find on YouTube. I must say, "Harden My Heart" sure brought back memories I didn't know I had, ha ha! Unfortunately the contrast in both videos is terrible. I tried several encoder settings but they didn't help (they're designed to improve VIC-II rendering of a good video, not fix a bad one). Most everything turned out as gray blobs

The only scenes that looked really good was the guy with a flame thrower at the end of "Harden My Heart" and the computer animation in "Walking on Ice". If I find the time, I might try creating a macro in PhotoShop to fix the contrast of all the frames in the video.

Hopefully all the bugs are now squashed in this version of MP128

Later this year I might start on the next version, but right now I would like to work on Digimaster(128).

tokra · « **Reply #46 on:** February 04, 2012, 11:46 PM »

Two thumbs up!

Just tried it on the 1541 U2 with 2.4c-firmware (=most recent). It works! I could watch the whole video. Great stuff.

The REU-wrap around-bug sure is a strange beast. There is some discussion on CSDB about this regarding the Limon REU Wave Player. From what I understand technically the 1541U would not need to reproduce the behavior of the 2MB-hack and could offer a true 16 MB-expansion. However probably for compatibility it emulates the bug as well now. And since I guess the 1541U is the most widespread 16MB-expansion it sets the standard.

If your software wants to be as compatible as possible it should expect the wrap-around bug in any case.

I don't understand one thing in your explanation:

Quote

- If the end address wraps, a flag is set and a check is made to see if the packet needs to be split
- If the packet needs to split, the length of the first part (current bank) needs to be calculated

Why do you need to check for a split if each packet is 4 KB? With each bank being 64K there should not be any splits because 16 packets fit exactly into one bank.

RobertB · « **Reply #47 on:** February 05, 2012, 08:13 AM »

Quote from: Hydrophilic on February 04, 2012, 10:01 PM

If your reading this RobertB...

Of course.

Quote

I downloaded the best versions of "Harden My Heart" and "Walking on Ice" by Quarterflash that I could find on YouTube. I must say, "Harden My Heart" sure brought back memories I didn't know I had, ha ha!

Yay! ... and the Dec. 31 Quarterflash 30th anniversary concert in Portland, Oregon was great!

Quote

Unfortunately the contrast in both videos is terrible. I tried several encoder settings but they didn't help (they're designed to improve VIC-II rendering of a good video, not fix a bad one). Most everything turned out as gray blobs

Darn! I could do a pristine copy of the "Take Me to Heart" video off the Geffen Records compilation laserdisc. For that, I'd have to dig out the laserdisc player.

Quote

...but right now I would like to work on Digimaster(128).

Oooo, that would be wonderful!

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

Hydrophilic · « **Reply #48 on:** February 08, 2012, 01:58 AM »

Quote from: tokra

I don't understand one thing in your explanation... Why do you need to check for a split if each packet is 4 KB?

Two different things. Loading data into the REU is easy because it is done 4KB chunks (and is not time-critical). Reading data out of the REU for playback was the tricky part, as the packets are variable length and resulted in the above 7 patches being needed (and of course playback is time-critical). Glad to hear it is working properly on real hardware, thanks for the feedback!

Thanks for the link to Limon player. One of the reasons I started this was because I couldn't find a media player when searched CSDb back in 2010. So maybe this has been an inspiration, or somebody is thinking on parallel tracks. 48KHz, that's a neet trick for a C64 (1MHz CPU)!! I wonder how they do that? I can only imagine it is hard-coded for specific frequencies and specific NTSC/PAL standard. It seems it does not deal with the REU bug and it does not detect end of file (that saves a 24-bit comparison which takes several precious cycles from an 8-bit CPU)...... I guess I should check it out.

Off topic (I'll start a new thread when I have something to show), I got Digimaster partially working on the C128. Had to totally re-arange the memory layout which means there is a bunch of code to patch and test: almost every address and pointer used

The GUI is up and running and loading/saving and selection is working. Need to work on the edit options, recording, and playback next.

RobertB · « **Reply #49 on:** February 08, 2012, 04:36 AM »

Quote from: Hydrophilic on February 08, 2012, 01:58 AM

...I got Digimaster partially working on the C128. Had to totally re-arange the memory layout which means there is a bunch of code to patch and test: almost every address and pointer used The GUI is up and running and loading/saving and selection is working. Need to work on the edit options, recording, and playback next.

Excellent progress!

You are the man!
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug