This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Hydrophilic
Pages: Prev 1 2 [3] 4 5 ... 49 Next
51
« on: January 09, 2013, 04:25 AM »
I don't have one to repair right now, but on behalf of the community, thank you. They're bound to come in handy!
52
« on: January 07, 2013, 05:02 AM »
It's not useless. In fact it seems fine except for strings. You just want to loop through all strings described above and, for any that are being killed, flag them for deletion.
You can use your FETCHz to read the back-pointers, and (when neccessary) use your STOREz to flag the string for deletion.
Maybe like this
LDA $39
LDX $3A ;end of variables
SEC
SBC #2
BCS +
DEX
+
STA $AC ;FETCHz using $AC
STX $AD
StrChk:
LDY #0
JSR FETCHz ;get low byte/length
PHA
INY
JSR FETCHz ;get high byte/flag
TAX
PLA
CPX #$FF
BEQ StrNxt ;already delted
... test address (see below)
... and get length from descriptor (see below)
StrNxt: ;A has length
EOR #$FF ;negate part 1
SEC ;negate part 2
ADC $AC ;effectively subtract length (low)
STA $AC
BCS +
DEC $AD ;effectively subtract length (high)
+
SEC ;$AC is at start of string, get next back-back poitner
SBC #2 ;size of pointer
STA $AC
BCS +
DEC $AD
+
;test if done
CMP $35
LDA $AD
SBC $36
BCS StrChk ;not yet, loop
Well that's the basic loop.
To check the address, I think it would be like this
;A,X has pointer to descriptor
TAY ;save A
;first check old start of arrays
CMP POINTERS+0 ;or Pointers + 2 ?
TXA
SBC POINTERS+1 ;or Pointers + 3 ?
PHP ;carry clear if address before arrays -- existed before PTRSAV, keep it
;look-up length from descriptor
STY $AE ;address of descriptor
STX $AF
LDA #$AE
STA FETCHz+1 ;switch to $AE
LDY #0 ;first byte of descriptor has length
JSR FETCHz ;get length
LDX #$AC
STX FETCHz+1 ;resume using $AC
PLP ;carry set if need to kill
BCC StrNxt ;not new string, keep it (see first code block above)
;flag string for deletion
LDY $AC
LDX $AD ;addresss of current back-pointer
STY $AE
STX $AF
LDY #0
PHA ;save length
JSR STOREz ;uses $AE -- set length in low byte
INY
LDA #$FF ;high byte invalid, flag deletion
JSR STOREz
PLA ;recall length
;StrNxt goes here... see first code block
None of this is tested, likely has bugs. In particular, I'm not sure if you should test POINTERS+0/1 (old start of arrays) or POINTERS+2/3 (old end of arrays). I think the first which is what is shown, but comments say "Pointers+2 ?" so you might try that.
I would just combine your code with that code. Then try simple test. For example create 1 or 2 variables then call PTRSAV. Then look at memory dump with monitor similar to screen shot shown above. Take notes. Then create a string variable. Check memory dump again and make more notes. Then call updated PTRRST and check memory dump again. Look and see if the new string has been flagged for deletion.
Good luck
53
« on: January 05, 2013, 04:46 AM »
This sounds possible, but unlike MS-DOS which writes disk layout information in the boot sector (first sector of disk), CP/M disks do not do this... as much as I like to bash Microsoft, that is one thing they got right! Anyway, this means that CP/M must "know" the disk parameters... if you've ever tried using CP/M disks from other systems using a 1571, you may have noticed a little pop-up window that appears at the bottom to select disk format.
There are a bunch of disk formats besides the 4 or 5 that is known by the Commodore build of CP/M. There is a program called Jugler that knows over 100 formats. But you have to run it every time you boot (there may be an option to modify CPM+.SYS). I don't think any of the formats that it knows apply to a DxM disk. So somebody would need to modify the XDPB of CP/M to recognize such a disk (as I understand, Jugler does this in memory when you run it, but does not update CPM+.SYS). Once the XDPB is updated for DxM format, it should work.
I would do it myself, but I would first need to upgrade firmware for uIEC to support DxM images. Very interesting idea, so I'll see if I can find the time.
54
« on: December 29, 2012, 12:57 PM »
I don't think you can map windows key... at least when windows is running... it intercepts all presses of windows key, AFAIK.
If you are running VICE in linux (or, you making stand-alone C128 emulator... cool) then should be able to map it... but I don't know how. So yeah, if anybody knows, give us the news!
55
« on: December 29, 2012, 12:39 PM »
I'm glad that helped. To change end of variables, you can POKE 49/50 to set end of scalar variables or POKE 51/52 to set end of arrays. Note if you change end of scalars you should also POKE 51/52 to the same value to erase all arays... otherwise you would need an ML program to copy old arrays down (or up?) Also you can POKE 57/58 to set end of strings... this is the real end of all variable memory. You didn't ask, but for completeness, start of variables can be set with POKE 47/48. You should use CLR command if you change either... or you would need another ML program to shuffle memory. I set the end and/or start of variables at the beginning of program so nothing is lost when I use CLR. I don't know why HA$ would be corrupt. If it is scalar it should not move... but if it is an array, for example H$(7), then a problem might happen when you use array killer. For example: H$(7) already exists, you call PTRSAV and then you change H$(7), and then you call PTRRST. Now there is a problem! When you change any string variable, a "back pointer" hidden at the end of the string data is updated with the parent variable entry.... so if you call PTRRST after changing an array string, the "back pointer" will be invalid. Use of this pointer makes garbage collection 10X faster than C64. But it also means you can't copy ML code that operates on strings directly from C64 to the C128. So don't change/create any strings between calls to PTRSAV and PTRRST. If you must, then you have to update your ML code! Here's how: - Start at end variables (57/58). At the very end of string memory you will find the back pointer.
- If back-pointer high byte is $FF, then it has been deleted/invalid.... the low byte gives the length... subtract the length+2 to get the next string back-pointer
- If the high byte is not $FF, then it is a valid string. The back-pointer is the address of the string descriptor (length, pointer low, pointer high). Use the descriptor to find the length... do check (see below)... subtract the length+2 to get next string back-pointer.
- Repeat until start of strings (53/54)
The important thing is when you find a valid string, to see if the descriptor is a variable you are killing. For example, if you are killing arrays (scalars too?) between $1000 and $1500, then if the back-pointer points to an address in that area, you need to mark the string as invalid. To do this, look-up the length from the descriptor. For example, if back-pointer is $1234, then length is stored at $1234 (and pointer to string at $1235/6). Once you know the length, store $FF to back-pointer high byte (flag invalid) and store length to back-pointer low byte. BTW, the length+2 in the algorithm above is to get the next back-pointer. For example, use the default configuration. End of strings (end of variables) is at $FF00. The first back-pointer is 2 bytes earlier, at $FEFE. Read the back-pointer from RAM at $FEFE/FF. If the high byte is $FF (invalid pointer), then low byte is the string length. Say 14 characters for this example. Then next back-pointer is 16 bytes before $FEFE/FF. So check again at $FEFE - (14+2) = $FEFE - $10 = $FEEE. Repeat if $FEFE is greater than start of strings (53/54), otherwise stop. (Remember you need to look up length from descriptior if back-pointer high byte is not $FF.) Now that I think about it, this applies not only to array strings, but also to scalar strings created between calls to PTRSAV and PTRRST. That is, if a created/changed scalar string was "killed" it, then it would also leave an invalid "back-pointer". Who knows what would happen if garbage collection is called when string data exists with invalid back-pointers? Don't want to dig through a ton of ML code. Best way to trouble-shoot is to create a simple example that demonstrates the problem. If a simple example doesn't exist, then it often is a mis-communication/bug between various modules. EditHave you had any luck with the string problem? Anyway, I thought I should explain the image I posted, in case it isn't clear. Starting from the end of variables-2, that is $FF00-2 = $FEFE for the default configuration, get the first string back-pointer. In the example screen shot, the back-pointer is $FF0E. Because the high byte is $FF, this string is invalid (flagged for deletion on next garbage collection). So get the length from the low byte = $0E = 14. Subtract length+2 (16) from current position ($FEFE remember) to get the next back-pointer at $FEEE. The back-pointer there has value $0402. Because the high-byte is not $FF this is a valid string. Now here is the important part. Look-up the length from the descriptor at $402. As shown in the image (last line), the descriptor tells us the length is 4 (it also tells us the string starts at $FEEA but we don't care). Now decide if this string is being "killed". Is the descriptor between the start and end of memory being killed? If not, do nothing (simple!). If it is being killed, store value $FF into the back-pointer high byte and the length (4, remember) into the back-pointer low byte. Either way, subtract length+2 (6 in this case) to find the next back-pointer at $FEEE-6 = $FEE8. Repeat checking back-pointers until you go below "free top" (the address in $35/36 = +53/54). In the example screen shot, "free top" is $FEEA (not shown). Because the next back-pointer should be at $FEE8, but this address is less than $FEEA, the search is complete. I would be glad to elaborate if anybody needs clarification.
56
« on: December 29, 2012, 10:10 AM »
Yeah, I guess there isn't a lot of software to work with DxM images. I even get error with the VICE utility program c1541 that works with most floppy image formats, but not DxM (maybe I did something wrong). Anyway, you can download Media Player 128 Gamma with Fast Serial Videos. It's a simple ZIP file. I think attachment is not working because I have slow upload speed and it takes about 1.5 minutes per megabyte (so about 4 minutes total). Unzip and you should see several MP128 files in the 'root' and subfolder called 'videoFS'. All the main player software is in the root folder (this is same as the REU release... the player is the same). So you can copy the player files to a 1581 / FD2000 / FD4000 disk. To run the player just RUN "MP128INI.BAS"
If you copy that file to disk first, then you can just RUN"*" (this of course assume use of unit 8... the player should work with any device but remember you need to add ,Un to the RUN command). The two videos in the folder "videoFS" are the just reduced-bandwidth versions of the REU version. You can copy (part) of either one to a seperate 1581 disk. You can copy either video in full to a seperate FD-2000 disk. You can copy both videos in full to a seperate FD-4000 disk. In fact you can copy everything to a single FD-4000 disk. Because 1581 won't hold full video, the player will just play how much fits on disk (about 1 minute, 45 seconds). Let me know if you need truncated version, because I imagine some software will whine and refuse to copy a file that is too big for a 1581. I think software should obviously warn you but should never refuse. Unfortunately not everybody consults me before releasing software (think of the money I would make). If you use seperate disks, then after the player is running, switch disks and click DIRECTORY to re-read the disk. If you use a different unit (for example, load player from 1581 unit 8 but videos are on FD-4000 unit 10) then once the player is running, select CONFIG > MEDIA FILES and change the unit to whatever you need. When you click OK it will automatically list directory of your unit. Once the files you want to play are listed, click on one or both to add them to the playlist and then click PLAY FILES. The same procedure can be used with uIEC (with fast serial firmware). This is confirmed working on NTSC and should work better on PAL. I don't think it will work on 1581 because of the track delay... well it may start playing but skip terribly. In older versions of VICE it would play fine in NTSC and PAL. In new versions it skips a little bit with PAL and skips horribly with NTSC. I would be very interested in real 1581 results. Videos do not play at all in VICE with FD-2000/FD-4000. This is either because the devices use FTL transfer technology or their is a bug in VICE. I would be very interested in results of real drive.
57
« on: December 24, 2012, 09:09 AM »
I made some videos that work fine on uIEC which transmit data ~56 microseconds. The 1571/81 transmit data in ~64 microseconds. Now the 1571 is too slow (and does not hold enough data), but the 1581 might could work. I don't own 1581 to test, but the video plays in older versions of VICE. Newer versions of VICE the videos play, but they skip horribly... I think because VICE now emulates track head delay.
I do not own FD-2000 nor FD-4000, but I made disk image to try in VICE. Well the videos do not play at all! It will randomly report BAD CODEC PARAMETERS, or FILE DATA ERROR, or just stop playing after 0.5 seconds. I think this is because VICE is sending data faster than 43 microseconds (VIC-II bad line period).
As far as I can tell, VICE sends data 24 microseconds after it is requested. I don't have FD drive to examine, but assuming it uses CIA 6526 clocked at 2MHz, then the fastest it could possibly send is 24 microseconds... in theory! For this to happen, the CPU in the FD would have to cram data into the CIA on the exact microsecond that the C128 requests it. I haven't examined the ROM of the FD units, but if it is anything like the JiffyDOS or 1581 ROMs, there is a huge delay between when C128 requests data and when the drive actually gives it to the CIA. Something like 32 microseconds.
So the drive ROM/CPU delay + CIA transmit time should be > 50 microseconds. Because that is much longer than VIC bad line, it should work on real hardware. Of course playback may skip because of delays reading the physical sectors, but it should at least play.
There is an option in VICE, "virtual device traps" which eliminates delay of ROM/CPU code and gives only the physical transfer delay (24 microseconds). But with this option off, it should include the full delay (50+ microseconds). However, no matter what options I try, VICE always seems to send at 24 microseconds. This just seems unreal to me.
Does anyone have FD-2000 they can test this video?
I've attached FD-2000 disk image (zipped D2M). I can also post 1581 disk image. I get an error trying to post FD-4000 image (even though it is less than 4096KB).
Just copy the disk image to a real floppy and RUN"*". It should load Media Player 128 files, and then show directory. Select one or both videos from the list (the two huge files) and then select PLAY FILES. The video should at least play (although it may "skip" during playback).
If you can test this on real hardware and report back, it would be very much appreciated. Please report type of disk drive and your system is PAL or NTSC, and naturally if plays or gives an error message. If it does play on real hardware, we can let the VICE team know and maybe they can fix the bug in next release.
58
« on: December 24, 2012, 07:22 AM »
You can download a zip file containing two of the videos, "Babylon 5" and "4 minutes" that use reduced bandwidth for direct playback on fast serial device. It only contains the videos, you still need the updated player, Media Player 128(gamma). They play on my NTSC system using uIEC. Other fast-serial devices may or may not work (they won't ever work with 1571)... The videos use reduced bandwidth for direct playback without need of REU, but due to this quality suffers a lot (which is why I didn't publish them first). Both reduced-bandwidth videos play at about 2.2 frames per second. Although marginally acceptable for "4 Minutes" it is just terrible for "Babylon 5" because of the fast-paced battle scenes. Most videos I've made use Multi-Color Bitmap mode because usually Multi-Color Text mode will run out of characters before it finishes building the image and looks really bad (if you watch these, you might not think it could be worse  ). However, "Babylon 5" is using MC text mode! I guess the vast areas of black "space" allow the scene to be built without running out of chars. (BTW, the REU version of "Babylon 5" is using bitmap mode). I used text mode in a desperate attempt to improve the frame rate. It only improved the frame rate about 10% (2.0 -> 2.2 fps), and naturally reduce the quality a bit. Of course the fast-serial quality is so inferior to the REU version that you wouldn't know... The encoder is still far from optimal, so no telling what is really possible. I think these videos (either fast serial or REU) demonstrate a much more consistant (but still not perfect) selection of color palette compared to previous versions. They also demonstrate a much better encoding when facing the "white problem" (see screen shot of "4 minutes" or "World Ends" in my previous post). One thing I just recently noticed that causes inconsistant palette selection. Near the end of the "Babylon 5" video, there is a scene that shows a zoom-in of Delenn. It starts and ends with a reasonable color palette. About half-way through the scene (which only lasts 2~3 seconds) it strangely switches to gray scale. Trying to figure out why the encoder would do this, I noticed that in the background some miscellanous Minbari comes into view in the background. He is wearing a white robe... so it seems that his appearance alters the statistics enough that a new palette (mostly grayscale) is selected... but as the camera continues to zoom in he is no longer visible and the encoder reverts original color palette. Watching the video, you probably wouldn't ever notice this background character had I not mentioned him... but he destroys the consistancy none the less. I really don't how to fix it! Oh yeah, videos "4 minutes" and "Babylon 5" are in wide-screen 16:9 aspect ratio. "World Ends" was originally in super-wide 12:5 aspect ratio but that resulted in only about 11 char rows (88 pixels) height. So the image was cropped horizontally with the result of 16 char rows (128 pixels) height... it now has some weird aspect ratio but I think it looks okay. The images posted previously were made in VICE without aspect ratio correction, so they appear a bit wider than real hardware. There is a bug with "low contrast" images. About 10~15 seconds into "4 minutes" there is a scene that is mostly black background and a dark gray floor... nothing else in the image. During this scene the encoder (for some reason yet to be determined) ended up dithering the image with rather huge blocks of black and green. Yuck! The same bug can be scene during the interior battle scenes of "Babylon 5". The scene has really bad lighting to start, and to make things worse the room is smoke-filled. Luckily the encoder doesn't try black-and-green to emulate dark gray (I think because it is mostly medium gray), but it still looks pretty bad. For the REU version, I manually increased the contrast for the interior battle scene so it looks a bit better than the fast-serial version. Of course the fast-serial version is using MC text mode, so the low-contrast images go from bad to worse.
59
« on: December 22, 2012, 11:03 PM »
I don't see an obvious problem, except that any scalar variables created between calls to PTRSAV and PTRRST will be destroyed in addition to arrays. For example,
CLR
A=1
X(0)=10
SYS PTRSAV
B=2
Y(0)=20
SYS PTRRST
In this case, array Y would be destroyed and so would scalar B. I assume that's how you want it to work? Or do you have different problem, like variable A or X(0) is destroyed? A simple example that demonstrates the bug that we can download would be helpful.
You can make it simpler by not copying all the data... assuming you don't have an old array. Example,
CLR
A=1
SYS PTRSAV
B=2
Y(0)=20
SYS FAST_PTRRST
This would destroy B and Y like before, and FAST_PTRRST is just
LDX #3
- LDA POINTERS,X
STA $31,X
DEX
BPL -
RTS
The fast/simple only works because there is no old array X that you need to keep (unlike my first example).
Edit
On second look, I think the bug is missing CLC...
LDA $AC
CLC
ADC #$01
STA $AC
LDA $AD
ADC #$00
STA $AD
LDA $AE
;missing CLC
ADC #$01
STA $AE
LDA $AF
ADC #$00
STA $AF
JMP PRST3
You might try this as simpler method
INC $AC
BNE +
INC $AD
+ INC $AE
BNE +
INC $AF
+ JMP PRST3
It works for me.
60
« on: December 22, 2012, 09:26 PM »
The End of the World is like the ultimate convention! Just don't call it TEOTW 2012 because that makes it sound like an annual event  It's more rare... bigger than Y2K... something like Y5812 if I understand the Myan calendar (which I don't). RobertB you sure know how to make a challenge! You want me to emulate Amiga generated video (Babylon 5) with a C128? Well I came up with something that looks just a bit better than total crap. Two other videos are also included: "4 Minutes" and "World Ends" ... so the theme of all of them is mass destruction. I've included a screen shot from each of them. You will need an REU to watch them or VICE. I have a lower quality versions that run on fast serial device uIEC. I also thought it would run on 1581... it works with 1581 emulation in older versions of VICE. But in new versions of VICE the playback skips horribly! I think because it finally emulates the 1581 track head delay (I don't own 1581). I also tried playback of fast-serial version with FD-2000 emulation and it is worse... does not play at all! Sometimes it will start and then quickly stop with 'FILE DATA ERROR' or won't start at all with 'BAD CODEC PARAMETERS'. Either there is bug in VICE or the FD-2000 is sending data faster than VIC bad line (about 43 microseconds). The 1571/81 send data ~64 microseconds so not a problem. uIEC sends every 48 microseconds so not a problem. I can post fast serial version if anyone wants it. How to play the REU version Download MP128gamma, and unzip to a (preferably new) folder. Then navigate to that folder using CD commands on a real machine, or in VICE turn off true drive emulation and set device 8 to the directory where you unzipped (Settings > Peripheral Settings). Type DIRECTORY and you should see several MP128 files. RUN "MP128INI.BAS" When the player is running, navigate to the "VIDEO" folder and select any or all of the included videos to play. If using VICE, be sure you have REU emulation enabled (Settings > Cartridge > REU) and size is 4096K or bigger. Videos will play with smaller REU but they will end early (how much ever will fit in your REU). Older versions of VICE do no list subdirectory... so if you don't see 'VIDEO' (file-type DIR) in the listing, select CONFIG > MEDIA FILES and change the path to VIDEO (erase anything else in path) and click OK. Videos take a minute or two to load into REU with VICE ( of course you can enable warp mode and it should take just a few seconds, but be sure to turn off warp mode before you start video playback ). If you are loading from CMD hard drive on a real machine, it is faster to unplug parallel cable if you have one... this is because parallel cable must be accessed by KERNAL calls which is much slower than reading fast-serial bus directly. Sorry if that is pain! I was really hoping it would work with FD-2000/4000 because you can fit a full video (or two) on one disk. I also wanted to make a simple .REU file that you could just load into 1541 Ultimate (or VICE) and then start up immediately... but I've run out of time... it's the end of the world, don't ya know? The videos shown here are VIC-II multicolor bitmap mode. The encoder is also making hi-res bitmap, MC text, hi-res text modes too. Those need more debugging so nothing to show now. The encoder is also setup to make EBCM and VDC videos but is completely broken at the moment. I hope to find the time to try that in my next life. It was great meating you all. Happy doomsday!
61
« on: December 22, 2012, 08:01 PM »
Thanks for the screen shots! And the info about making the case... Round holes aren't much of a problem, but based on your description, the DB9 connection sounds like a pain to make. So, again, job well done!
62
« on: December 12, 2012, 08:20 PM »
Ray is the man; if he can't fix it, no one can! Seriously, I find this very fascinating. I tried looking at the schematics to see how this could be... but I can't find U113 or any 7414 chips. I guess that is because I only have schematic for flat model... so I guess it has something to do with the extra electronics for the 1571. I find it really strange that floppy drive electronics would mess up the video; well I understand something shorted out could mess up the voltage and ruin the entire video, but totally baffled how it could mess up only the cursor... and how STOP+RESTORE would fix it! Do you or Ray have any thoughts about this? I thinking understanding the problem is just as important as knowing the solution...
63
« on: December 10, 2012, 07:51 PM »
At least I am not the only one imagining the color red when it isn't there. Hmmm... I saved the screen shot as JPG for posting on the forum... it looks substantialy the same as the uncompressed BMP screen shot, but I still wonder if that makes it look it has red when you zoom in. Assuming your monitor has proper color balance, any red phosphors / LEDs in the gray areas should be matched by green and blue so you shouldn't see red, just gray... but the fact there physically is some red sub-pixels on a color monitor probably enhances the illusion.
Anyway, thanks for the replies guys! I like the site you linked, wte... The animated "pink" dot is a great example, and they have lots of other neat illusions... my favorite is probably the "Mirror of Truth" with the shirt that says Love / Hate. I would pay for one of those.
64
« on: December 07, 2012, 09:58 AM »
Ah, the sprites are 64x24... now that makes more sense. Although the game seems to use standard (24x21) sprites, I can see how combination/overlay can make an effective size of 32x24... just goes to show I didn't pay very close attention to the details when playing. Anyway, it sounds like a very interesting exercise; good luck and have fun!
65
« on: December 05, 2012, 06:43 PM »
I used VDC software sprite in MP128 (quite complicated... see related, simpler, VDC arrow), but it is in 8x8 text mode so probably not much help. So 64x24 in mode 8x2 mode = 512 horizontal (nice) and 48 vertical (wtf?). Ummm... is the vertical really 24*4=96 ? 64x96 in mode 8x2 = 512x192 ... that sounds much better to me, but I'm just guessing. So are you using bitmap or text mode? In text mode, I calculate 64x96 = 6144 for text matrix + 6144 for attributes = 12K which leaves 4K for font on a 16K system... nice! Or bitmap mode I calculate 64*192 = 12K for bitmap + 6144 for attributes = 18K... too big for a 16K system but allows 3 full screen buffers on 64K system... also nice! Anyway, I hope you get something working that can sure with the rest of us.
66
« on: December 05, 2012, 06:01 PM »
The video encoder seems to be doing a fair job with "extreme" color scenarios now (see previous post); it is a LOT better than the original for sure I went back and tried re-encoding some videos from before and noticed a nice improvement with the color. Unfortunately it STILL has tendancy to oscillate between palette choices, but at least it is much less frequent. I'm beginning to suspect that due to limited color selection, their is not a 100% reliable method... well I mean you can impose certain restrictions to gaurantee a reliable output, but I've found that user-imposed restrictions will prevent some really nice-looking (i.e., superior) images generated automatically (more about this below)... Right now, I wanted to talk about the opposite problem: "low" color scenarios. Although the VIC-II has lower color saturation than the VDC or other systems of the era (for example Nintendo Entertainment System), its colors are still fairly well saturated (50%+ exact amount debatable). One good example is the video "Stronger" by Britney Spears. In this video, she appears extremely pale. I don't know if it is due to her flesh tone (she is definately much darker now), due to makeup, due to lighting, or due to camera (or combinations thereof). See the first attached image which shows a source frame (i.e., frame of video in 24-bit color before my software mangles it). Hopefully you can see her flesh tone is mostly pink / light red... but it is a very "washed out" (gray-ish) red. In other words, neither VIC-II "red" nor "light red" is a good match. One method to implement this is with heavy dithering with gray. Unfortunately so much gray gets used in the dithering process that (light)red becomes a very small component. Not suprisingly, previous version of encoder rendered much of this video (about 50% for shame!) in gray-scale. I'm glad to report the new method (described in previous post) does a much better job of picking out color. Unfortunately it is still not 100% reliable (similar to "extreme" color mentioned first). As an example see the secod attached image. Note it is not the same frame as the first... it occurs 2 frames earlier in the video. The important thing is that it gray-scale. So as an example of how the encoder has improved, see the third attached image. It is the same frame as the first image but rendered in 4 fabulous VIC-II colors I hope you agree the third image (color) looks better than the second (gray). Question: how many shades of red do you see in the third image?
When I look at it, I see light red... although a very "grayish" light red. This is only natural considering it is heavily dithered with white. *** SPOILER ALERT **** Take a moment to examine the third image and make a conclusion before you continue reading... . . . If your vision is superior to mine, or if you used photoshop etc. to examine the image, then you know the answer is zero. There is no red in the image! Yet it definately appears like it has red to me... this is especially true when watching the video, as opposed to a detailed frame analysis like we're doing here. The four colors used in the image are Black, White, Cyan, and Green (sorry, I forgot to note if it is dark or light green). So why does it look like it has red? Well if you don't see red, then maybe it is just that Hydro has ecentric color vision. Assuming you do see red, my theory is that because green, and especially cyan, are far from red on a color wheel, that the human vision system imposes the "complement" (red) on any grays (in particular black). So what do you guys think? I find this a rather intersting feature of the human vision system and/or my video encoder. I don't really know how to take advantage of it in code... search for two opposite colors to a low use color? I also have a fourth image I can post if anyone is interested. It is where I force the encoder to use light red. It looks very similar to the third image, but Britney's hair does not look blonde at all... more of gray/pink. So the third image is a good example where not forcing an arbitrary palette can produce superior results. I mean I could code it such that: IF ANY (LIGHT)RED THEN ALWAYS USE (LIGHT)RED but as mentioned before, these types of "rules" prevent unexpected/suprior results shown here. Any / all comments on the topic appreciated!
67
« on: December 04, 2012, 12:26 PM »
Just fired up Pool of Radiance again cuz you mentioned it... wow... character creation is just a great feature that is missing from most modern RPGs. Of course pre-set characters let you immediately jump into the game, but really they should give you the option. After spending over an hour setting up a party I walked around town and then saved the game without doing anything Well actually I was looking at how it might be ported to the C128. Considering it uses both multi-color mode and sprites, it looks like you are in for quite a challenge. I imagine it would end up looking like a ZX Spectrum game. Hopefully with the 'larger' screen of the VDC you can make the graphics 'bigger'. I mean if you keep 24 columns for text on the right, then you can have a 'massive' 56 characters on the left for the graphic window (assuming you don't get fancy with custom VDC settings). Well if you get anything working, I'm sure people would love to see it. Good luck!
68
« on: November 26, 2012, 06:59 PM »
I wanted to report success and failure with work on color in my video encoder. I was hoping to improve speed and quality/consistancy by using image statistics and an indexed look-up table. The theory was it is much faster to compute the statistics once, then use a look-up table to find the optimal color for each cell. Well it is faster, but the results are highly unstable (small variance = very different palette choice) and still not optimal... sheesh. I tried indexing the color spaces (set of colors assigned to palette) in various ways: average luminance, luminance span, luminance variance, min/max luminance, and again for hue and saturation (12 indexes as I recall). I tried just about every simple combination (2 or 3 values considered together) and eventually wrote a routine that would combine any/all of them with a weighted formula; something like a*L1+b*L2+c*L3+d*L4+e*H1+f*H2.... where the L1, L2, etc. and H1, H2, etc. are the index values and the a,b,c,d, etc. are the weights. Still could not get good consistant results... I believe the problem is missing colors in an area with a large hue (or luminance) span. For example, imagine an area that needs RED, YELLOW, and CYAN (that is 180 degrees of hue) plus possibly some gray. Often (maybe 50%) the average hue and luminance work out such that "best" color space would be something like RED, GREEN, CYAN, and BLACK. This could be because there is a lot more CYAN than RED/YELLOW (skewing hue towards GREEN) and/or that GREEN gives a better luminance than YELLOW/BROWN. The important thing, in this example, is that GREEN was choosen even though it is not needed... a wasted color. Note this wouldn't be bad if the C128 had 256 colors, one or two bad choices (some wasted colors) would be okay. The problem with the articles I've found addressing the color palette issue (see the one referenced in my last post for an example) is they assume the device has a reasonably large number of colors (16 or 256 for example). Well technically the C128 does have 16 colors but they can't be all freely assigned so you're limited to 2 or 4 colors without invoking sprites (which of course is not possible for VDC). In other words, existing technical docs (that I've found) aren't very helpful, except for theory. (more on that below) Let me qualify the previous and say that index tables do not work well for a large area (for example to select the background color of multi-color bitmap) but does work okay for individual cells. This is further evidence (to me) the problem is due to large span with 'missing' colors. Although it works well (most of the time) for cells, I don't believe it is optimal most of the time (just from appearances, no scientific tests performed). So back to the drawing board... I can now report some success with a modified brute force method. Brute force was used in previous version but it was slow and highly unstable. Before it would dither the whole image multiple times with various color combinations... typically 12~24 times ? (I'm not sure; it would vary and in any case was quite a lot). So imagine dithering 32k pixels with a set of 4 colors and repeating 20 times = 2.5M tests. Not a big deal if you got 100+MHz CPU and need just one image. More of a problem when making a video (even with 1GHz CPU)! The modified method does one pass and generates an 'impossible' image. Where every pixel can be any chip-specific color (no mode limitations). Then it just picks the most used values after some sanity checks. For example, lots of green and light green could be replaced with a single light green by dithering with black (assuming black is needed, which is very likely). Of course if only green and light green were needed (for whatever reason) then it would use them both. Another example would be choosing white instead of light gray (discussed below). So now its like 32K * 16 colors * 1 trial = 0.5M tests. So I'm guessing about 5x faster (and same or better quality). Again, I haven't preformed any scientific tests but the speed improvement is very evident. I'm thinking now the results could be improved by doing a second pass. But instead of 16 colors, use 4 colors selected from the first pass, plus 1 or 2 'trial' colors... that is colors that are very close to the ones used the first time. I need to test it, but I've seen several frames that should benefit from such a treatment and the total computation would be 32K * 16 * 1 + 32K * 5 * 2 = 32K * 26 = 0.8M tests... Obviously more than single pass, but still about 3x faster than original 2.5M tests! But that would be for another day... Just as important (more so to me) is better results with the "white problem." Refer to previous posts (possibly a different thread), but basically the problem is with a palette of 4 colors if you need both black and white then you have only 2 colors left and if the hue span is large (greater than 180 degrees) then you can never produce a perfect image. Of course it should be possible to produce an "acceptable" image given the constraints. Now that is one issue where the theory I've read made evident the problem I noticed before (the white problem is one example). There are several ways to describe it. From a mathmatical perspective, it is like using the correct area of convergence for a line integral. From an electrical perspective, it is like designing for the extreme voltages or currents. If this isn't done correctly (in some cases it is impossible due to 4 color limit) then you get "out of bounds" errors which result in something like thermal runaway. I think that's a good analogy if you're into electronics. Like a transistor with more current than designed, it heats up, which lowers the resistance, which allows more current, and thus even more heat... etc... fried transistor. Luckily you can't harm the C128 by making/watching a bad video (I don't think) but the problem results in ever-increasing error residuals (used to dither the image). It has some really "cool" effects. "Cool" as in interesting / unexpected results, but just terrible in terms of image quality. I can post some images if you like, but the results can be described as image "bleeding" ... similar to an over-exposed photograph. Even more extreme is error "overflow" (wrap-around). This produces areas that are like a photo-negative. So previously I had to incorporate error reducers and limiters. The first (reducers) helps eliminate the "bleeding". In both the original and new the user can adjust this. If you set it too high (too much reduction) the image doesn't dither at all but it gaurantees no bleeding. Luckily the default values provide a good compromise but you can always tweek it. The second (limiters) should not be needed with a reasonable reducer but it is still used in case the user is unreasonable ANYWAY (wow this is a long post) the issue is enclosure. Sometimes it is not good enough to select the most used or best colors, but instead the extreme colors (or luminances). The "white problem" is a good example. Before the results were so bad that I simply used an ugly hack... reduce the contrast. That is reduce brightest color to light gray. While it gave "acceptable" results, I was not very happy with it. Well the new method seems to work "acceptably" with white and lots of color. I've attached several before and after images so you can judge for yourself. I think the best video to demonstrate the problem is Katy Perry's California Girlz. I picked a few frames at random from one video made with old software and the closest frames with new software. Note I was lazy and just let the new software run automatic... there is now option to manually pick and choose individual frames and I could have picked the exact same frames... but yeah, I'm lazy. I think overall the new version looks better, but in the first example I think the new version is worse, sigh. It forgot to include blue/cyan! Since I made the screen shots, I think I have fixed that problem (I guess I should verify). By the way, the screen shots were made with an older version of VICE which does not correct for the aspect ratio, so the images are a bit wider than a real C128.
69
« on: November 24, 2012, 11:57 AM »
I'm glad you tested it and it works without need to constantly BIT $D600 or verify the VDC copied the correct number of bytes.
So I think it is about as fast it can be. If it is slow, you can blame the VDC.
I only see a few minor things that would improve speed. But they are so minor that the user would probably not notice any difference.
For example, you could change
...
inc j
bne Vdcwait
inc k ;update data pointer for next go around
VdcWait bit $d600
bpl VdcWait ;wait till fill done
jmp Loop
...
to something like
...
inc j ;update data pointer for next go around
beq FillHi
VdcWait bit $d600
bpl VdcWait ;wait till fill done
jmp Loop
FillHi inc k ;fix high byte
bne VdcWait ;always, wait till fill done
...
This adds 2 bytes of code (BEQ FillHi) and saves 1 CPU cycle on average (but adds 4 cycles when the high byte wraps). Normally this is 255/1 ratio, so you should expect to save 255*1-1*4 = 251 cycles for every 256 codes. So if you have 1000 Fill codes in a file, it would save about 1ms. Nobody would notice.
Likewise you could make this change:
bne Loop ;<-- was BNE skipinc0
inc k
skipinc0 jmp Loop
exit rts ;done
This will save 3 cycles for every Skip code and never add any more. Arguably better, but again if you have 1000 Skip codes in a file, it would only make it 3ms faster.
Silly me, I was thinking of 1MHz! The VDC code is probably running at 2MHz so the total savings of 1+3 = 4ms in my examples would actually be 2ms. Again, only Flash Gorden would perceive a difference.
70
« on: November 24, 2012, 11:27 AM »
I don't own one, so I've refrained from posting. I don't understand why the ROM would have a problem... I do know that the IO chips can't be accessed at 2MHz, but I thought it was hardware feature of the C128 that does clock stretching to IO chips. Maybe the RAMLink by-passes this somehow?
For example, without scrolling the screen, you could try writing something "harmless" in the IO area. For example Color RAM.
10 POKE 53296,1:REM FAST
20 POKE 55296,1:REM WHITE COLOR FIRST CELL
30 POKE 53296,0:REM SLOW
You could also use a FOR loop to write to all 1000 color cells.
Anyway I was thinking earlier that this could be the problem, because when the screen scrolls all of the text screen and color RAM must be moved.
I didn't say anything because I was also thinking that the C64 writes to ColorRAM anyway with every use of PRINT... well I know it does on the C128, but not sure about C64 ROM. It seems like it would, but I'm not sure.
More important, this seems like a serious issue, because many commercial programs invoke 2MHz on the C64 for a speed boost during the borders (of course it has no effect on a real C64).
71
« on: November 20, 2012, 09:26 AM »
I would change BNE to BEQ when testing for the terminator, because it is very uncommon (should only execute once). I also would move it so it only is tested 1/4 of the time (only when needed) :
Loop ldy #$00
lda (j),y ;get data
lsr
bcs fill ;1 to 127
lsr
bcs copy ;copy 8 bytes 1 to 64 times
beq exit ;data stream done
Skip ldx #$1f ;we sending 1 to 63 bytes to vdc
...
skipinc0 jmp Loop
exit rts ;done!
This saves 3 cycles for each Copy and Fill code, and 1 cycle for each Skip code. It does add 1 cycle for the Done code, blah.
Have you tested it? Hopefully it would work as is, but I've had problems writing to the data register ($1f) without religiously checking the status bit. Access to other registers doesn't seem to need it.
So if you have unreliable results, you might want to add a check in the Skip and Fill routines. Like this example for skip (similar for Fill) :
skipinc lda (j),y ;get byte
skipwat bit $d600
bpl skipwat
sta $d601 ;value into reg
...
Finally there is a problem that I hope does not affect you. Some of the VDC revisions have a bug with Copy operation. There is really ugly code in the Editor ROM that tests the end address after the copy operation is complete and adds another 1 byte to copy if the copy operation failed to copy all the requested bytes. I did not need to use this ugly hack with my Battle Blox game (last program I wrote that used VDC copy), and hopefully you won't need it either! It may be the bug only appeared in the prototypes that were used when CBM wrote the ROM, and the released machines are okay.
72
« on: November 20, 2012, 05:43 AM »
Wow the case is impressive. Not exactly heavy metal, but it sure looks tough! Tougher than sheet metal, for sure. I can imagine what a pain it would be to get all the holes aligned and sized correctly ... not fun with plastic (which is easy to work), so even more impressive with thick metal. Great work! If anybody doesn't like it, you can throw it at their head. That should change their mind Any screen shots?
73
« on: November 18, 2012, 04:05 PM »
Here are some interesting things I've discovered looking at the BASIC 4.7 source. This may be old news to actual CBM-II (PET?) owners (not sure how the PET version 4 differs). Anyway, there is a bug in the DOS parsing routines. It tries to limit the device number to a serial device (4 to 31) but suffers from "off by 1" bug. This means you can specify device 3 (screen) for commands DIRECTORY or DSAVE. It will "crash" (infinite loop) if you try DIRECTORY -- it reads until "end of file" but the screen never sets "end of file". I thought it would be cool to DSAVE to the screen, but although DSAVE allows device 3, it just passes the call onto SAVE which says ILLEGAL DEVICE NUMBER. Well next I tried SCRATCH and you can SCRATCH the screen That's where I saw another interesting feature of V4.7 -- this is a minor incompatiblity and not really a bug. In direct mode, commands SCRATCH and HEADER will ask "ARE YOU SURE" which I think most of us know. As you might expect, typing Y will allow the command to proceed. Entering anything does not start with Y (for example N) will cause the command to abort. However, different from V3.5 or V7.0, is that not anything that begins with Y will work. On those machines you could answer "YEP" or "YA" or "YES SIR" and the command would work. But in v4.7 you can only enter "Y" (alone) or "YES" (alone). Anything else will fail. I found that very peculiar, but since it only effects direct mode, it shouldn't cause any problems with program compatibility. One thing that might effect compatibility is the FRE() command. On most versions of BASIC this takes an integer argument. Of course machines like C64 don't care about the value (only 1 bank of RAM). Most of the CBM-II machines put program text in seperate bank than variables, like the C128. But an incompatibility I found was v4.7 allows a string argument while v7.0 does not. Specifically, any string argument will return the free space of the bank that holds the strings (this will vary depending on the amount RAM, or really the ROM version which is built to match). Of course any program using FRE() to determine string data location would probably fail on other machines anyway. But I still found it interesting this feature was removed from v7.0
74
« on: November 18, 2012, 10:53 AM »
Never seen one, but very interesting find! I'm sure our German members could say better, but I don't see a product name in the advert, just makreting hype (a new, econimically priced, 16-bit MS-DOS compatible system). So it is the SX-PC  ? I hope somebody has more info!
75
« on: November 18, 2012, 10:32 AM »
It could use optimization, but that looks pretty good for a first version. I don't see any obvious problems, except the Fill operation. You read the count and add 1... so you can copy 1 to 64 bytes. But then you store that value directly in the VDC count register ($1e). This would actually write 2 to 65 bytes, because 1 byte was already written by store to data register ($1f).
For example, lets say code value is $87. You strip the high bits and add 1... now 'temp' has value 8. I assume you really want to write 8 bytes...
...
ldx #$1f
jsr IncAdr
lda (j),y ;get value from datastream
jsr VdcWrite ;<-- this writes 1 byte
ldx #$1e
lda temp ;example 8
jsr VdcWrite ;<-- write 8 more bytes (total 9)
...
In the example, 9 bytes get written. As long as the encoder knows that $87 => 9 bytes, this is okay. If it thinks 8 bytes then it would generate a corrupt image.
Otherwise the code looks fine. There are lots of ways to optimize it, but much more effective than using bits 0,1 would be to replace all those JSR with in-line code. That would save about 12*4 = 48 cycles per code byte (even more for copy). I'm sure you know that. Anyway, thanks for sharing!
Pages: Prev 1 2 [3] 4 5 ... 49 Next
|
Show Posts
