Recent posts

#1

S

Emulators / Re: ACE for Linux,Mac, Windows...

Last post by SyX - Today at 14:42

MERCI @roudoudou!!! Another wonderful release and I can edit text now

#2

S

Games / Re: Converted GX4000 .cpr - Th...

Last post by SyX - Today at 13:25

@SyX , a little bit of topic, but the more I play this FLIPULL+ version, the more I'm asking myself if it would be possible to convert the game on CPC? With these new GFX, you give a CPC touch to the game, more than a "Plus" touch. But I suppose the "spaghetti-code" would be a real pain in this exercise?

It looks like I have lost the ability to explain something in a few words, sorry xDDDD

After 150 pages, a little off-topic is going to disappear, then we can indulge in it for a few seconds.

As I said before, I didn't want to touch this game at all, because I felt that the GX4000 game is not a good game. And I only saw minimal graphical improvements and that is all. 

But RedAngel saw something that I didn't, then I took a better look at it and I felt that this game could be converted to the classic CPCs without too many problems. And it is perfect, for everything that I have been talking about the first generation of gx4000 games: they were developed in a hurry and they started as classic cpc games.

Sure, after looking at that awful code, I thought of a few alternatives:
1.- I could port the zx version, all the logic is there and because it is not an advanced game, all the graphics could be improved to use mode 0. I even could use overscan or egx if I was crazy enough.

2.- Because the game logic is not complex and when I was a child and I saw the arcade, I made a few tests in basic using the cpc font as graphics. Well, 30 years later, sure that I would do that in assembly or even c in a few evenings. There are already two CPC games inspired in plotting; Inferno, a 1994 public domain game, it looks basic but it is in overscan; and Hot Plot, a type-in from a German magazine.

But after the first scary look, at the end of the day I don't need to touch that spaguetti code too much. In fact, Flipull+ is only redirecting a few of the bugged routines to my patched ones or they are patched directly.

The problem or blessing is that RedAngel had already revamped the graphics, adapted the nes levels and converted a lot of the new backgrounds. Starting a CPC version would mean remade everything again. And if I wanted to use all the backgrounds, I should load new backgrounds after a few levels or up the specification to 128 KBs machines or disk drives (neither of those things are bad, in fact in my mouse patches if I can, I use 128 KBs and floppy drive for hiscores, because if you have a mouse expansion, then you should have more expansions surely).

Then a CPC version is more than possible, the original cart organization is:
* Page 0: Game engine that it will go in $0000 and a few fonts (uncrunched)

* Page 1: Game engine that it will go in $8000 (includes bytes at 0 that are used as ram variables or working space when is copied to ram), game tiles (uncrunched)

* Page 2: Map, Fonts, logos, huds (everything uncrunched) and the menu code.

* Page 3: Sprites, fonts, other graphics (everything uncrunched)

* Page 4: Backgrounds 1-3

* Page 5: Backgrounds 4-6

* Page 6: Music player, song, ... and the last two backgrounds

* Page 7: Uncompressed loading screen 

With that information, we can consider that for making a CPC 464 version, we should start by converting the loading screen into a real loading screen (we load and forget!), cart page 7 is not necessary anymore. Then we can put our video memory in $C000.

We are going to skip the backgrounds for now, that means cart pages 4, 5 and half of page 6 are not necessary anymore.

I am lazy, the menu sequence is going to be shown once; the first time, after the game is loaded, after that it will go out of the RAM. 

Of course, I will not store the HUDs uncrunched, they would be drawn using tiles. And we don't need two copies of every tile; one when they are tiles and a second time when they are cpc+ hardware sprites. Meaning that I can put everything graphic related and the levels map, everything that lives in cart pages 2 and 3, now they will live in $4000. Surely, I can put the arkos player and the new songs in $4000 too.

Cart page 0 goes to $0000 and page 1 goes to $8000. The code changes that I need to do are: replace the cart pagination code, we can NOP those bytes, and CALL directly to our routines that are already in memory. And replace the routine that copies sprites to the sprites in the asic ram, for our sprite routines.

Now for extra credits, we can look for empty space in RAM for putting all the compressed backgrounds that we can get, and that is, you have Flipull for CPC.

... although if we have been making all this work, why should we be using the spaghetti code? The code necessary for handling this game is not hard. In fact it is a wonderful project for somebody that wants a funny project for a few months.
.
.
.

@iXien, I hope that you are starting to enjoy the game, seriously, the more you play it, the better the game is, hehehe.

And you can return to the topic now!

#3

Technical support - Hardware related / Re: cable DDI-1 for CPC 6128

Last post by Rabs - Today at 13:15

Would I be ok if I accidently got the cable upside down?

#4

Technical support - Hardware related / Re: CPC 6128 - white screen, b...

Last post by McArti0 - Today at 12:32

Test 74LS373 by spider hardware

#5

Emulators / Re: ACE for Linux,Mac, Windows...

Last post by roudoudou - Today at 11:55

Hi, some dev updates and an annoying bugfix...
http://www.roudoudou.com/ACE-DL/

Code Select Expand

- Bugfix FDC Head reload with ReadData (some residual code left...)
- Automatic time counters with Execution Breakpoints (min, max, current)
- HexFind and TextFind in Memory Explorer (press F and N to repeat)
- Text Edition in Memory Explorer + Text selection
- AY registers color change on modification
- FDC ReadTrack timings when Not Ready
- Snapshot default memory banking

text edition will still need some improvments in the future (a full keyboard mapping at least...)

#6

Technical support - Hardware related / Re: CPC 6128 - white screen, b...

Last post by McArti0 - Today at 11:37

no way of knowing if their test is running as expected or not and the results can't be trusted.

Test is Pin 24 z80 WAIT is permanent Lo after Step 3

#7

Technical support - Hardware related / Re: CPC 6128 - white screen, b...

Last post by McArti0 - Today at 11:01

@Bryce.
Notice that the clock inverter gets a heavy zero at the input - it has no chance of ticking even once. The freeze is sure and strong.On the address lines there is &B100 or &B101. I use rectifier diodes so they have a 60ns propagation time, they may not stop at the first LDIR address.

#8

M

Technical support - Hardware related / Re: CPC 6128 - white screen, b...

Last post by mmldrm - Today at 10:47

If the jumper wire is lying across the PCB and (as is the case here), the user doesn't have a scope to confirm the clock signal, then they have no way of knowing if their test is running as expected or not and the results can't be trusted.

I do have an oscilloscope now! And pin grabbers/clips should arrive today.

I know my kit was woefully inadequate initially (and still isn't ideal now) but hourly these will provide more reliable test results.

Thanks again for putting up with this situation.

#9

Technical support - Hardware related / Re: CPC 6128 - white screen, b...

Last post by Bryce - Today at 10:41

Just out of interest. Have you actually tried to do this setup in reality and confirmed it works? Or is this all based on theory?

I did exactly that yesterday. Everything I write in this thread is tested (on real CPC16128)

The reason I ask, is that connecting anything at all directly to a crystal pin will usually dis-balance the capacitance enough so that
the clock will either not start at all or will be unstable.

And that's how it should work. GA is supposed to permanently turn off the clock and thereby freeze itself in a specific state.

Well that's at least good to know. However, there's a reason why those capacitors and the 74 are extremely close to the crystal with very short traces. Just the additional capacitance and inductance of the extra wire is enough to disturb the clock. If the jumper wire is lying across the PCB and (as is the case here), the user doesn't have a scope to confirm the clock signal, then they have no way of knowing if their test is running as expected or not and the results can't be trusted.

Bryce. 

#10

Technical support - Hardware related / Re: cable DDI-1 for CPC 6128

Last post by SerErris - Today at 10:32

That is what I said:

Amstrad PIN 1-33 are signal pins, where shugart it is the even pins (2-34).

So we are talking about the same signal pins, that are never GND. At best they are NC.

Amstrad did just turned the connector arround, so that even will be odd and also that PIN 34 will become PIN 1 (READY)

Following that The Amstrad PINs 29,31 and 33 carrying +5V from diskdrive to power the controller (Amstrad Schematic) and that will convert to PINs, 2,4 and 6 on Shugart BUS.

As described above, all of those are signal pins and not connected to GND on shugart bus. Pin 2 and 4 are drive to interface pins, so there should be a pullup on the interface side (or on the drive side), but there is nothing driving the line from the interface to low and interface side should be on high impedance, so it should not be an issue. 
Pin6 however could be a driving pin with driver select 4. However on the CPC infrastructure, the DDI-1 does not use this line for anything (as well as DS3). 

In the Schematics of the 6128 Service manual, it looks like the cable would be connected to +5V...
You cannot view this attachment.

However looking at the board, they are really not connected.
You cannot view this attachment.

Anyhow, regardless if you connect it with cut lines or not, it will not harm the CPC (which we agree on :-) ).