6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 16, 2024 9:05 am

All times are UTC




Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Jun 09, 2017 7:10 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
GARTHWILSON wrote:
djangojames wrote:
What is the MTTF for an SSD? It was about four years old...

I've seen a lot of first-hand reports on the forums of SSDs not lasting very long. I'm not ready to depend on one until the durability is improved. For now, we do have quite a system of daily automatic backups here at home (to mechanical hard discs), thanks to our son's server in the garage. It also has its own backups. It's just better to not need to go through the process of restoring everything though.


My oldest SSD is, I think, pushing 6 years old. It's my work machine. I run databases, do source code builds, other generic data processing on it.

Only failure I've heard of here at the office was the one in the laptop of a guy in our analytics group, and he was constantly reloading very large databases.

Most of our main production filers are now SSD as well. We have TBs of the things.

I back up to a regular hard drive (Mac OS Time Machine), but that's more simply because $$/byte is better than SSD, and performance is secondary. I would like to get rid of it, though, simply because the machine does a hard stall when the drive spins up.

At home I have 2 SSD in my machine, plus a hard drive backup. My wife's laptop is SSD, and she backs up to an SSD. Form factor wins there. It's basically a thick credit card that she plugs in every couple weeks.

Modern SSDs with modern OSes are much better at spreading the load out on the devices, giving them great working life.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 09, 2017 11:53 pm 
Offline

Joined: Tue Feb 24, 2015 11:07 pm
Posts: 81
djangojames wrote:
Image

The fifth one down is very nice indeed.

I have some 30-odd SSDs, mostly in the data centre and have had two failures in the last ten years, one 30GB ADATA mSATA device and one 160GB Intel 320 series. Over the same period I've had 2x Seagate HDDs and 1x WD HDDs fail, not that any of this is statistically significant. At least it's easier to get vendor diversity in the SSD arrays, although I have to pay attention to vendors re-badging the same chipset.

Backup is automatic daily (pull SSH) to a ZFS pool with daily snapshots going back 12 months, so I can pull the state of any file within the last year. ZFS zero-cost snapshots rock. And on-line de-duplication if you have the RAM: I've 16 GB allocated to the backup server and a dedupratio of 2.93x.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 09, 2017 11:57 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
BTW, if you added more vertical spacing between lines of text, it would make the non-consistent-baseline font much easier to read.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 10, 2017 3:42 pm 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
I am now wondering if the SSD failed because of my misunderstanding of how mmap works- I have never had a HDD fail before in 20 years, guess I have been lucky.

Here's the same text in the two other fonts, thanks for all your suggestions.

Image
Image


Last edited by djangojames on Sun Jun 11, 2017 10:26 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 10, 2017 5:48 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Both screens are ways better to read than the previous ones. :D

I would suggest choosing the upper screen font when your adventure is an ancient fairy tale or s.th. related to knights and trolls etc.
The lower screen font would nicely fit to some space_star_challenge_war_adventures me thinks.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 10, 2017 11:41 pm 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
So I had my first go at images! Woo. No 6502 compression yet, that's next on the list. For now just experimenting with converting images to use...

Image

https://github.com/djangojames/exploratory/blob/master/blog.md

GaBuZoMeu, Yes that gothic one is ace. I found it on a bitmap font editor website (and heavily edited it to fit 8x10 pixels). I need to find and credit the original designers. You've spotted the central theme of the game... trolls AND spaceships...


Last edited by djangojames on Sun Jun 11, 2017 10:27 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 12:06 am 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
And more, Image


Last edited by djangojames on Sun Jun 11, 2017 7:28 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 6:33 pm 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
Final images... I promise. Next I will post some actual 6502- I'm going to move onto image compression. Is there a section for this, or should I just keep posting here? What I really need is some of you assembler wizards to critique the number of cycles I am using...

Image

Image

Image

I'd love to see how these look on a real C64 on a flaky old CRT TV. I aim to have this running on VICE or similar, but to enter the IF competition I will build a simplified 6502 emulator in JS so it can run in the web- with only the minimum graphics and I/O I need. I might not get round to making the code actually run on a real (or real emulated) C64. Having said that, I am not doing anything to preclude it.

https://github.com/djangojames/exploratory/blob/master/blog.md


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 8:29 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8541
Location: Southern California
djangojames wrote:
I'm going to move onto image compression. Is there a section for this, or should I just keep posting here?

I would be interested to see 6502 discussion on image compression, in the "Programming" section. Making it to be general-purpose might attract more readers than it would be if it appeared to be specific to video games. Be sure to post a link here to the new discussion.

Garth (moderator)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 11, 2017 10:30 pm 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
Thanks Garth

I have begun jotting down my thoughts on it here, https://github.com/djangojames/exploratory/blob/master/blog.md

I will post something to the Programming section when I have some code to show.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 13, 2017 5:13 am 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
djangojames wrote:
I'd love to see how these look on a real C64 on a flaky old CRT TV.

Yeah, the current scanline rendering in the posted images is way too harsh, as the lines should have some glow around them and not be stark black between 2 bright lines. It'll look a lot better even in VICE with its CRT emulation. (that is, unless the output is actually putting alternating black pixel lines on the c64 display, which will retain the harsh look)

However, when it comes to converted graphics, remember that 320x200 on a 4:3 display does not yield square pixels, so things will look more stretched on the real thing. Shrinking it down to 267x200 for modern square-pixel displays would give the same pixel aspect as a C64+CRT (or double it up to 640x400, then shrink to 533x400 for scanline-style display).

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 13, 2017 9:32 am 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
Thanks, that's useful information. The black scanlines are part of the my renderer, so reducing the harshness should be straightforward (half bright alternating lines?) Scaling to a non-integer aspect ratio may be trickier with the code I have- it's just a simple blit at the moment. I'll have a look at the VICE code to see how they do it- they probably use some tricks to speed things up. I imagine each rendered pixel has to take a sample from the source image in the right proportion- I imagine this is how white pixel bleed can be simulated too.

Image compression is going well- I can get the girl's face from 1352 to 869 bytes with a hand-rolled version of LZ77. Decompression will be super easy as there is no fancy bit bashing or multiplication needed.

Still not enough IMO as I want to have an image at every location in the game. I am thinking of some strategies to improve it, given that it doesn't need to be entirely lossless...


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 17, 2017 8:08 pm 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
Finally, some 6502. I spent far too long fiddling with the compression algorithm but I finally came up with something that works. Now I can put images in the top right corner of the screen.

Image

The compression algorithm is super simple. Any pattern longer than three bytes is indicated by a special byte, the LFB. Following the LFB is a byte which contains the length of the pattern in the hi-nybble and the offset to the pattern in the lo-nybble. The LFB is chosen as the least frequent byte in the source image. If it is seen, it is replaced with a zero. Look away now if you disapprove of this kind of hack :wink: Because images are spatially coherent, a special value for offset of "0" is used to indicate a match on the scanline directly above. In the initial version of the decompressor, matches are not allowed to go over a scanline. This severely degrades the performance- I can improve this later if I find that I am running out of memory to fit all the images in.

Code:
 ;+ DECOMPRESS
             ;Expect the height in A
  DECOMPRESS 09E6 850A    STA $0A
             09E8 A000    LDY #$00
             09EA B100    LDA ($00),Y
             09EC 8508    STA $08
             09EE E600    INC $00            ;SRC
             09F0 D002    BNE $09F4          ;COPY-ROW
             09F2 E601    INC $01            ;SRC + 1
    COPY-ROW 09F4 A200    LDX #$00
             09F6 A000    LDY #$00
             09F8 A50C    LDA $0C
             09FA 8509    STA $09
             09FC A90D    LDA #$0D
   COPY-BYTE 09FE A100    LDA ($00,X)        ;X should be zero
             0A00 E600    INC $00            ;SRC
             0A02 D002    BNE $0A06
             0A04 E601    INC $01            ;SRC + 1
             0A06 C508    CMP $08
             0A08 F019    BEQ $0A23          ;PATTERN
             0A0A 9102    STA ($02),Y
             0A0C C8      INY
             0A0D C609    DEC $09
             0A0F D0ED    BNE $09FE          ;COPY-BYTE
     ROW-END 0A11 18      CLC
             0A12 A502    LDA $02            ;DEST
             0A14 6928    ADC #$28
             0A16 8502    STA $02            ;DEST
             0A18 A503    LDA $03            ;DEST + 1
             0A1A 6900    ADC #$00
             0A1C 8503    STA $03            ;DEST + 1
             0A1E C60A    DEC $0A
             0A20 D0D2    BNE $09F4          ;COPY-ROW
             0A22 60      RTS
     PATTERN 0A23 A100    LDA ($00,X)        ;X should be zero
             ;Get the pattern offset from the lo-nybble
             0A25 290F    AND #$0F
             0A27 D003    BNE $0A2C          ;SAME-ROW
             ;Pattern is on the row above
             0A29 18      CLC
             0A2A 6928    ADC #$28
    SAME-ROW 0A2C 850B    STA $0B
             0A2E A502    LDA $02            ;DEST
             0A30 38      SEC
             0A31 E50B    SBC $0B
             0A33 8504    STA $04            ;PREV
             0A35 A503    LDA $03            ;DEST + 1
             0A37 E900    SBC #$00
             0A39 8505    STA $05            ;PREV + 1
             ;Get the length from high nybble
             0A3B A100    LDA ($00,X)
             0A3D 4A      LSR
             0A3E 4A      LSR
             0A3F 4A      LSR
             0A40 4A      LSR
             0A41 18      CLC
             0A42 6903    ADC #$03
             0A44 AA      TAX
             ;Advance past the match byte
             0A45 E600    INC $00            ;SRC
             0A47 D002    BNE $0A4B          ;PATTERN-NEXT
             0A49 E601    INC $01            ;SRC + 1
             ;Now we have offset in PREV and length in X
PATTERN-NEXT 0A4B B104    LDA ($04),Y
             0A4D 9102    STA ($02),Y
             0A4F C8      INY
             0A50 C609    DEC $09
             0A52 F0BD    BEQ $0A11          ;ROW-END ;End of pattern and row
             0A54 CA      DEX
             0A55 F0A7    BEQ $09FE          ;COPY-BYTE ;End of pattern
             0A57 D0F2    BNE $0A4B          ;PATTERN-NEXT
             ;- DECOMPRESS
         ODD 0A59 09      /home/dan/Downloads/odd.bmp pixels (1166)
         ODD 0EE7 00      /home/dan/Downloads/odd.bmp colours (162)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 18, 2017 3:53 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
What factor of compression are you seeing?


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 18, 2017 7:09 am 
Offline

Joined: Wed Jun 07, 2017 1:22 pm
Posts: 16
Some example sizes for images,

Code:
           
               Original Simple Best

cellardoor     1352     1073    995    26%
porsche        1352     1182   1042    23%
maxine         1352     1054    762    44%


I've implemented the simple scheme, but am working on the extension to make it a bit better. This involves removing some of the constraints in the LISP compressor, but leads to more complex code in the 6502 decompressor to handle scan-line spanning. Additionally there are 169 bytes of colour data and that does not compress at all well. (Like typically 20/30 bytes saving). There is probably a better scheme to be had there.

There's more detail and the original images at the blog here https://github.com/djangojames/exploratory/blob/master/blog.md#1562017-the-compresssion-rabbit-hole


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: