Chunky Pixel Curator - WIP

[ervin]

@erving , any chance for a scan of those photos?

Alrighty, you asked for it!


http://i69.photobucket.com/albums/i57/poppichicken/2854aeec-95eb-41c7-b990-273be2d71ae9.jpg
http://i69.photobucket.com/albums/i57/poppichicken/88c42b30-689e-481d-b228-f568ea8b277e.jpg

Wow... those photos must be 28/29 years old.
Holy cow. Where have the years gone?!?!

Looks like I'm playing Knight Lore in one of the photos (judging by the map), and working on a programming article from ACU in the other.
I'd love to know which issue that programming article is from, but the photo isn't clear enough.

[EDIT] Found it!
I was working on page 66, of the March 1985 issue of ACU (I was typing in Trench Attack)!
It's amazing; to this day I remember typing that one in and running it (and not having any idea how it worked!)... glorious memories.

[robcfg]

Hehe, nice pictures!


I think I have some very similar pictures of myself with my Amstrad.

[Carnivius]

Ah, so this be what you mentioned before with the scaling routines?   It's pretty neat and I found the use of Roland on the Ropes sprites very amusing. 

[ervin]

Hehe, nice pictures!

I think I have some very similar pictures of myself with my Amstrad.

Yeah, I look a bit different these days!
A bit thinner and quite a bit older! 

[ervin]

Ah, so this be what you mentioned before with the scaling routines?   It's pretty neat and I found the use of Roland on the Ropes sprites very amusing. 

Yep, that's the one! 

And I can finally say (with these bugs out of the way) that the engine is finally completely finished!
(Well, until the next bug is found).

Content can now be full steam ahead!

[AMSDOS]

In that code is a POP IX and a PUSH IX.
It used to be POP AF and PUSH AF.
I can see why it caused a crash - the ADD HL,DE was changing flags and therefore corrupting the AF that I had stored.

However, that worked in WinAPE, which leads me to wonder if WinAPE isn't treating the flags properly in such a case...

I was reading in my Assembly Book that ADD HL,reg alters the Carry flag, but nothing else. So I'll probably have to check some of my assembly routines which is using ADD that happily runs in Winape.

[ervin]

I was reading in my Assembly Book that ADD HL,reg alters the Carry flag, but nothing else. So I'll probably have to check some of my assembly routines which is using ADD that happily runs in Winape.

Yes, the carry bit being changed in the F register is what was corrupting my code.
Silly mistake on my part.

[CraigsBar]

But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.

[Bryce]

But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.

Looks like the 4128plus has become your new "standard machine"

Bryce.

[CraigsBar]

He'll yes. I love it. I am even thinking of moving the symbiface onto my Amstrad Cpc 6128 and shelving the 2 6128 pluses. The upgraded 464plus is certainly my number 1 Cpc now.

[ervin]

But the fix is good, I tested this on my 4128plus last night. And it's lovely on the real hardware.

Excellent! REALLY glad to hear that it is working on real hardware!

I'd love to get some more testimonials from 464, 664 and of course 6128 users.

[CraigsBar]

I can do that tonight on Cpc 6128 but I don't have Cpc 464 or 664.
The 6128plus will work, it's the same mobo and asic as the 464plus after all.

[ervin]

I can do that tonight on Cpc 6128 but I don't have Cpc 464 or 664.
The 6128plus will work, it's the same mobo and asic as the 464plus after all.

Tremendous, thanks so much for your help.

[Carnivius]

I would try but I don't think I have the stuff to get a dsk file running on my 464.

[ervin]

I would try but I don't think I have the stuff to get a dsk file running on my 464.

No probs, thanks anyway.

[TFM]

Waiting for the next update with some more rooms. 


I think walking that way is just great. All this turning around is always confusing me. 

[Gryzor]

Thanks for the photos mate, they really put a smile on my face!

Unfortunately my parents didn't see it fit to take any of me using it back in the day...

[AMSDOS]

Yes, the carry bit being changed in the F register is what was corrupting my code.
Silly mistake on my part.

Though interesting it was originally working in Winape, you might have to forward a copy of the original to Richard so he can work out why Winape's not crashing. 

[ervin]

Though interesting it was originally working in Winape, you might have to forward a copy of the original to Richard so he can work out why Winape's not crashing. 

Yep, I reckon I might just do that.

[Carnivius]

Having to ask the author of a software as to why it's NOT crashing?  What a strange inversion. 

[ervin]

Having to ask the author of a software as to why it's NOT crashing?  What a strange inversion. 

It's certainly the first time I've ever needed to do that!

If it is indeed a problem with the emulator, it's probably just a small Z80 core inaccuracy.
In any case, it's very easy to work around, and certainly doesn't appear to have been a problem for all these years.

[opqa]

My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.

The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.

[ervin]

My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.

The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.

Interesting... in that case the error is probably with the H flag, as the operation isn't a subtraction.

[andycadley]

My bet is that the crash is related to the H or the N flag. 'add hl,de' affects C,H and N flags.

The C flag is widely used and an error with that one would have been noticed long ago, but on the contrary H (half-carry) and N (set if the last operation was a substraction), are rarely used, they don't even have dedicated jump instructions.
Moreover, in a discussion I recently had with Syx in a spanish forum he told me precisely about this. He knew for sure that WinAPE doesn't handle the undocumented flags correctly. He told me that it was because it uses directly x86 flags, that are equal for the "standard" ones (C, P/V, Z maybe S...) but not for the others.

ADD HL,DE will also affect bits 3 and 5 of F, flags so obscure they don't even officially have names!

[Executioner]

ADD HL,DE will also affect bits 3 and 5 of F, flags so obscure they don't even officially have names!

It's most likely one of the obsure flag bits like bit 3 or 5. I will be fixing the flags for the release after next.