Z80 Homebrew Computer - fault finding

[grumpydoc]

Congratulations on getting it working

I must get back to my own Z80 build 

[nockieboy]

Congratulations on getting it working

I must get back to my own Z80 build 

Thanks grumpydoc.  I'm sure you'll be fine with your build!

So let's say I want to page a 16K block of RAM.  I'm using a 128K SRAM chip, with A16 grounded so only the lower 64K is used currently.  The memory map would look something like this:

FFFF  ----------------------------
         | Reserved for CP/M   |
DC00 ----------------------------
         | TPA                          |
D000 ----------------------------
         |                                 |
         | 16K TPA PAGE AREA |
         |                                 |
9000 ----------------------------
         |                                 |
         | TPA                          |
         |                                 |
0100 ----------------------------
         | 'Low Storage' area  |
0000 ----------------------------

Hmm.. how would I go about mapping the middle of the block of RAM to another block of RAM?  (That's a rhetorical question, btw - I'm sure there must be documentation on how it's done out there, I just haven't found any in the short time I've had to search for it!)  It would be simplicity itself to swap out the entire 64K of RAM by making A16 go HIGH, but that wouldn't work all as CP/M and the stack etc would be swapped out with the lower 64K...  So what's the best way to switch the middle of the lower 64K block with any 16K block from the upper 64K in hardware?

[grumpydoc]

Congratulations on getting it working

I must get back to my own Z80 build 

Thanks grumpydoc.  I'm sure you'll be fine with your build!

With luck, it might be a bit ambitious on the clock speed front.

So let's say I want to page a 16K block of RAM.  I'm using a 128K SRAM chip, with A16 grounded so only the lower 64K is used currently.  The memory map would look something like this:

FFFF  ----------------------------
         | Reserved for CP/M   |
DC00 ----------------------------
         | TPA                          |
D000 ----------------------------
         |                                 |
         | 16K TPA PAGE AREA |
         |                                 |
9000 ----------------------------
         |                                 |
         | TPA                          |
         |                                 |
0100 ----------------------------
         | 'Low Storage' area  |
0000 ----------------------------

Hmm.. how would I go about mapping the middle of the block of RAM to another block of RAM?  (That's a rhetorical question, btw - I'm sure there must be documentation on how it's done out there, I just haven't found any in the short time I've had to search for it!)  It would be simplicity itself to swap out the entire 64K of RAM by making A16 go HIGH, but that wouldn't work all as CP/M and the stack etc would be swapped out with the lower 64K...  So what's the best way to switch the middle of the lower 64K block with any 16K block from the upper 64K in hardware?

Depends on whether you want the switchable block to be arbitrary or at a fixed location and whether the addresses line up nicely with address bits.

If you are targeting CP/M 3 you want a common block at the top of RAM and then switchable banks in the remaining space.

Let us suppose that you choose to implement an 8k common area at the top of RAM (which is a bit more convenient than 16k) - in this case feed the top three bits of the address bus into an AND gate. That combination will give you an active high signal when the address that the Z80 is trying to access is between 0xE000 and 0xFFFF.

As you have 128k RAM use whatever means you fancy to decode a single output bit.

The RAM needs 17 address bits - A₀ to A₁₂ come direct from the processor. For A₁₃ to A₁₆ drive the outputs from 4 OR gates. One input of each OR gate will come from the active high signal described above. Then for the OR gates connected to A₁₃ to A₁₅ on the RAM the other input comes from the corresponding CPU address line and the final OR gate is connected to your I/O bit.

The result is that any access by the Z80 in the range 0xE000 to 0x FFFF will cause the top 4 address bits on the RAM to be '1' and so will go to the last physical 8k block in the RAM. If your I/O bit is '0' then accesses in the range 0x0000 to 0xDFFF will go to RAM addresses 0x00000 to 0x0DFFF, when your I/O bit is '1' accesses in the low 56k of Z80 address space will go to 0x10000 to 0x1DFFF in the RAM (i.e your bit give you two banks).

You can see how it should work in the schematics for my build.

The slight disadvantage in the above scheme is that you loose a page of memory (because you can't access 0x0E000 to 0x0FFFF in the RAM - any address in that range gets mapped to 0x1E000 through 0x1FFFF). Consequently my design is a bit more complex in that it uses an adder to do the mapping without loosing any RAM (which works out nicely with 512k - you get an extra bank).

More complicated schemes might involve using a fast SRAM to create a mapping between Z80 address and physical address (old cache SRAM chips can be useful for this) or even using an EPROM to set up a mapping. I've posted schematics for this sort of thing in the past.

You could replicate a similar scheme to direct all accesses in the range 0x00 to 0xFF to the bottom 256 bytes of physical RAM but I chose to avoid the extra gates that would require and will work around keeping all the interrupt vectors the same in all banks in software,

If you really want an arbitary block anywhere in memory to be remapped then you need t think about using RAM to implement a "page map" as above or implement something similar to the Z180 line of CPUs with registers, comparators and adders to juggle the memory map around.

[nockieboy]

I think when I get a moment I'm going to have to hunt through your previous posts grumpydoc and look up these schematics.

I'm not looking to reinvent the wheel - I'm not experienced or knowledgeable enough to design my own memory mapping system, just want to include the simplest system compatible with CP/M 3 that will allow me to make use of the upper 64KB of my SRAM.

On a complete side note - I've been hunting for a female PCB header that'll accept the 44-pin 2" IDE male pins from the CF adapter I'm now using (thinking ahead to if/when I get a proper PCB made up for the SBC so I can just slot the CF adapter into it without the IDE cable and wire rat's nest I've got going on at the moment.) Is there such a thing I can search for? The pins are obviously closer together than the 2.54 pitch breadboard holes.

[C]

First do not think small.
You have a 128k ram now, why design something so limited?
It would be nice to be able to easily add a lot more ram.

Think a moment, Think your CF card adds many drives with large disk blocks. If the Drive block size is not equal to 128 bytes, when you need a File buffer to use disk drive. With out enough memory for file buffers, you can end up when updating a 128 byte CP/M block to disk having to do a Read from disk, Modify the 128 byte block in the buffer and the writing to buffer back to disk. 
In addition you need more buffers to handle directory updates.
With CP/M3 and turbodos, both try to keep common high memory space small.
Also at times Both would like to copy from one block to a second block.
 
So 128k can work, but more memory is better. 

Think you are thinking one swap area to save lo logic.

For example, Just because hardware can swap all memory in X size blocks, That does not mean you have to swap and area.

Simple 16k system
You have four 374's with Z80 IO write to inputs. You now have 6 more address lines, you lose two to replace the two used to select one of four chips. This gives you any 16k block from a 1m address space.
One of the four 374 is selected based on outputs from a 138.
138 A & B are connected to Z80 A14 & A15
One address input of 138 is not needed & 138 has many inputs to control outputs.
So you have four 374's with all outputs connected to A14-A21.

Now the problem with above. At power up the state of the four 374's is unknown.
By changing C input  of 138 you could switch to a second set of four outputs.
Or you could use one of the other inputs to disable all outputs of 138
In both cases you have a tri-stated upper address bus A14-A21.
Final step us connect one output of 273 do disable this 138 by one of the two methods above. A low from 273 gives no valid output from 138 which does not enable a output of 374's, leaving A14-A21 in tri-state..
8 pull-up resistors connected A14-A21 can give a known state with both of above. When not driven A14-A21 will be high.

Your existing rom program needs to exist at the address with A14-A21 all high.

You have a 128k ram chip. If my math is correct, then 8 of these memory chips will fit in 1meg. If you use a 138 to decode 1 of 8 then just attach your 128k ram to  Y0 & your Rom to Y7.

Said a second way
1. 138 chip selects which 16k space the Z80 wants( only two address inputs used and 4 outputs are used).
2. 4 374 chips. The 138 enables output of 1 of 4 374's. This gains 6 address bits.
3. The 273 disables all outputs of #1 138 on power up. this leaves A14-A21 in tri-state.
4. 8 pull-up resisters pull A14-A21 high when in tri-state.
This is the memory mapper for 16k. Each 16k area can come from a 16k block in the 1 meg memory space.
5 138 or 139 This is chip that is used durring Z80 write to select one of the four 374's.

So the 16k memory management takes 6 chips

1M address space.
1. 138 decodes 1meg space into 8 128k spaces for your Ram chip.
2. 128k ram chip is connected to Y0 from #1.
3. ROM is connected to Y7 from #1. Power-up boot program has A14-A21 high during boot. Your existing boot program needs to be written to correct area of rom so that it is present with A14-A21 high. A rom smaller then 128k will repeat in memory, this is ok.

Now you need a software change to boot rom to set the 374's to a known state at some point.
For Rom basic you just write proper value in first 374 to keep rom in memory map and set remaining to point to ram. Then do output to enable.
If Rom is larger then 16k you can have many rom programs to chose from.

First step for CP/M is use rom to read CP/M boot from disk. Switch to all ram and jump to CP/M boot now in ram.

Note this has been edited many times.

Note above the use of a 1 of 8 decoder(138) to do a 1 of 4 decode. This is just to have extra inputs for when you need a valid output. A 139 is two 1 fo 4 decoders so it could select which 375 is used on Z80 IO write & select which 374's output to become extended address.
If you want to have many Z80 IO outputs you have four ready to use with 138.

The 139 with it's dual 1 of 4 outputs is a great chip if you need Four input addresses and four output addresses. 

Now this all fails if it takes too long in time. You have memory address delay of 138 connected to Z80 + 374 output enable delay + 138 delay selecting which chip from 1meg memory. This is added to memory chip times.

Would be great if 1meg 138 output was enabled by MREQ. If this is not the case then a two inverters in series can add some delay to MREQ.

Logic has to be good & times valid for your 8meg Z80 at clock speed.
 

[grumpydoc]

First do not think small.
You have a 128k ram now, why design something so limited?

Reasonable comment

You have a 128k ram chip. If my math is correct, then 8 of these memory chips will fit in 1meg. If you use a 138 to decode 1 of 8 then just attach your 128k ram to  Y0 & your Rom to Y7.

But why muck about with 8x128k RAMs to get a meg when you can simply get a a couple of 512k x 8 or 1M x 8 chips (the latter if you don't mind SMD packages)?

[nockieboy]

Hey grumpydoc - slight diversion from the current memory mapping discussion, but I was trawling your posts for hints and tips on said subject when I found this image:



That's exactly the same PC-IDE adapter card I was having trouble with... I'm assuming it's working fine for you?  Maybe I've got a dud card with the earthed RESET pin?

If I can get one of those cards that actually works, the connection to the SBC would be much better via the IDE-GPIO than the current IDE cable and rat's nest of connecting wires.

EDIT: It'll also make finding a PCB connector a damn sight easier to find, too!

[grumpydoc]

Hey grumpydoc - slight diversion from the current memory mapping discussion, but I was trawling your posts for hints and tips on said subject when I found this image:



That's exactly the same PC-IDE adapter card I was having trouble with... I'm assuming it's working fine for you?  Maybe I've got a dud card with the earthed RESET pin?

Don't know yet.

The board moved on slightly since then - I've changed it so that I can flip the CF card above the PIA/SIO. I've also finished placing all the sockets and power routing and am about 1/3 of the way through wiring the logic together. It ground to a halt a bit while I looked at the PM3394B CPU and digitiser boards for EHT

[C]

First do not think small.
You have a 128k ram now, why design something so limited?

Reasonable comment

You have a 128k ram chip. If my math is correct, then 8 of these memory chips will fit in 1meg. If you use a 138 to decode 1 of 8 then just attach your 128k ram to  Y0 & your Rom to Y7.

But why muck about with 8x128k RAMs to get a meg when you can simply get a a couple of 512k x 8 or 1M x 8 chips (the latter if you don't mind SMD packages)?

128k as that was stated ram size OP has. 

[grumpydoc]

But why muck about with 8x128k RAMs to get a meg when you can simply get a a couple of 512k x 8 or 1M x 8 chips (the latter if you don't mind SMD packages)?

128k as that was stated ram size OP has.

Yeah but 8 of them is a pain to wire up.

It's even a bit of a pain to solder into a PCB, compared with a single package.

[nockieboy]

Yeah I think for simplicity and cost a (couple of) 512Kx8(s) is the better option.  I understand where you're coming from regarding the 1MB of memory space, but in reality I'm never likely to use anything close to that (my original intention was to build something roughly equating in size and power to my old Amstrad CPC464 that I had as a kid in the 80's. That was just a 4MHz Z80A-powered machine with 64KB memory. I've already doubled the processor speed and included CP/M which never factored into the stock 464.)

Of course, since starting the project I've been hooked by learning huge amounts about digital electronics and the 'what if' and 'how much else can I squeeze onto this' mentality. 

There I was thinking I'd make a start on integrating the PSG, or SPI (yeah, the 464 never had that either), and instead I'm looking at massively increasing the available RAM.  This isn't going to be a short project, but the amount of learning I'm doing is awesome.

[C]

As to memory, it is easy to change if you make it that way. Your on a breadboard so some what already easy.

Think of my solution above. It is just one way of doing it. It does the rom to ram change. You could have many banks of rom. Now break it down some.
To change 0-16k from rom to ram for me is one added chip. You have Grants version. The 273 version of grant's for number of chips. Think you might find the 273 easer to understand. The point is powerful can be simple. And always many ways to do something.

If you have looked at some of the expandable computers. Some you set jumpers to change hardware settings..Some use an 8-bit magnitude comparator such that a dip switch can change settings like address range.
Now a logic signal can disable the 16k mapper. You would be using this to handle power up. But you could also use this another way.
Grab a gate that 8 low inputs gives an output. Connect the inputs to A8-A15 on Z80 and you have a signal for 0-255 bytes address. This could disable mapper and enable common memory.
One of my Z80's uses a  8-bit magnitude comparator to change address of common memory and memory based IO.
A disable signal could let you have a second set of memory or put a IO port in middle of your ram..

There I was thinking I'd make a start on integrating the PSG, or SPI (yeah, the 464 never had that either), and instead I'm looking at massively increasing the available RAM.  This isn't going to be a short project, but the amount of learning I'm doing is awesome.

Might want to think on the areas you want to learn more about.
How much could something your learning here help you in the future.

Good to look at other ways to do things.
For the 8080 an interrupt is forcing a call instruction on bus.
The Z80 could do this, but Z80 chips like SIO are built for Vectors. And a vector is one byte where a call is 3 bytes.

Most old computers with Video output used dual port memory built from normal memory. A dual port memory chip is great, With great cost for small size memory in one chip.

In simple, There are many things you could learn from a Z80 & 68000.

When you pick something to learn and do. look at other ways also. You might also think about how much what you learn could help in future.
SPI is good for a CPU talking to Fast IO over few signals. But you have to read a byte to get status in place of reading a port. SPI slave has no way to slow the data rate but a status bit or status message.
An SD card can function with High data rate, Can an ad Arduino supply or receive data at these rates as a slave?

AY-3-8912 I would leave this chip to collect dust. Think most you learn here is just AY-3-8912 knowledge. But it's your choice.

You are at a point where you can learn a lot about software.
You are also at a point where many things hardware can be easer to do now.

Think of this as a project, Connect your two Z80's so that it becomes more then a single Z80. To start with connect the two serial ports. Then add a port so one Z80 can reset the other. Each time when you add more RE think the hardware and Software. Can a change make it faster or more powerful?


 

[C]

Now that you have Grant's CP/M running, what TPA size do you have for CP/M programs?

 

[nockieboy]

Now that you have Grant's CP/M running, what TPA size do you have for CP/M programs?

Good question.  Hmm... according to his documentation, the TPA area is 0100-D000.  That equates to CF00, or just under 53KB.  When I run Microsoft BASIC-85 Rev 5.29 under CP/M, it's reporting 29,752 bytes free.

[C]

There is a software way to ask CP/M and it should show on CP/M boot also just so you know.
53k Not real bad but not great.
What you don't know is how much limited system space is slowing system.

I would guess buffer sharing is being used which slows disk use.

If your not going to do much that size TPA can work.
You could learn a lot getting CP/M3 or turbodos running, both hardware & software.

For me the important thing is to help you learn. To really do this you need to understand what is happening in software & hardware. How it works, What other options are there.
It can be a real pain when you do not know something exists.

So have fun and let me know how I can help.

 

[nockieboy]

So have fun and let me know how I can help.

Thanks C - certainly will do.  For the moment I'm going to focus on the software and getting my monitor program rock solid (I still have much to learn with assembly, it seems!)  Hardware-wise, I'm going to tidy up the breadboard a little and replace the jumper wires with more permanent wires.  I've added in the FT232RL board already, so I don't need  the flimsy USB/TTL lead any more and can use a standard USB cable.  Having seen grumpydoc's image of the same CF-IDE adapter I was having trouble with, I'm considering getting a replacement in the hope that mine was, for some reason, faulty (with the earthed reset pin) as it will connect to the SBC much more easily than the current solution.

No doubt I'll be back soon - but thanks for the memory management info, I'll certainly be looking into expanding the RAM in the system.

[C]

Software wise the same thing can sometimes be done many ways.

Grant's SIO init
  He is using a series of OUT instructions. This makes a settings change to SIO hard( not need here just example)
A different way would be to put in a data table and use a loop to output to SIO.

When writing software, think of writing a book.
When you write C you gain a little data of what goes in and comes out a function.
Try to to better when writing assembly. Will save time later.
Big comment blocks before each sub.

[nockieboy]

Okay, preliminary schematic for the PSG (AY-3-8912) expansion for the SBC.  This is being built on a separate breadboard.



I'd welcome any feedback at all on the design - it's partly based on what I could find elsewhere on the interweb, but the interfacing control signal logic (such as it is) is my own creation.  Looks like the AY-3-8912's BDIR, BC1 and BC2 are active high, so I've run the IOWR, IORD and signal from the Y1 pin on the '138 through an '04 inverter so they make sense to the PSG, whilst not confusing me too much.

By my rough calculations, an OUT to address 08H (or anywhere in the 08H-0FH address range) will write to the PSG.  An IN to address 08H will read from the PSG.

However, whilst writing the above sentence I've spotted a possible issue.  I need to get BDIR and BC1 both HIGH to latch an address in the PSG - which effectively means I have to get IOWR and IORD LOW at the same time which, if I'm not mistaken, isn't possible?!

Here's the logic table for the PSG functions:

                IOWR   IORD    Y1
                BDIR     BC1     BC2
Inactive      0          0         1/0
Read           0          1           1
Write          1          0           1
Latch Addr  1          1           1

Any ideas how I can control the PSG as per the logic table above?  There's another pin, A8, on the AY-3-8912 that acts as an additional pin for DA0-DA7 to double the memory range, but I'm not sure if I can use that at all to control access to the PSG...  I'm a little stumped at the moment.

[nockieboy]

Oh - turns out A8 CAN be used as an extra chip select as it has to be high, otherwise the bidirectional buffers go into high impedance.

Still not sure how to solve the latch address control problem though.

[grumpydoc]

Still not sure how to solve the latch address control problem though.

BDIR is WR (i.e \$\overline{WR}\$ inverted so it is active high), BC1 and BC2 can be from A₀ and A₁ - you might need to gate them so that they are all 0 if the chip is not selected.

Treat A8 as an active high chip select and drive it from the inverted output of a 74xx138 connected to the higher order address lines.

EDIT: The datasheet notes that you can pull BC2 high and just use BC1 and BDIR.

[nockieboy]

Still not sure how to solve the latch address control problem though.

BDIR is WR (i.e \$\overline{WR}\$ inverted so it is active high), BC1 and BC2 can be from A₀ and A₁ - you might need to gate them so that they are all 0 if the chip is not selected.

Treat A8 as an active high chip select and drive it from the inverted output of a 74xx138 connected to the higher order address lines.

EDIT: The datasheet notes that you can pull BC2 high and just use BC1 and BDIR.

Thanks grumpydoc - I'd forgotten I could use the address lines to control the chip too... 

Yes, I've got \$\overline{IOWR}\$ going to BDIR and \$\overline{IORD}\$ to BC1, both inverted, with \$\overline{Y1}\$ from the 138 going through an inverter to BC2.  I'll pull A8 high by connecting it to Vcc through a 1K resistor (is the resistor is necessary?)

I like your solution of using A₀ and A₁ to control BC1 and BC2, though for my setup I'd use A₀ to control BDIR and A₁ for BC1 as per my logic table earlier, with \$\overline{Y1}\$ controlling BC2 through an inverter.

So, with that setup, the following should be true?

* An OUT 09H should WRITE to the PSG
* An IN 0AH should READ from the PSG
* An OUT 0BH should LATCH ADDRESS in the PSG

[grumpydoc]

Yes, I've got \$\overline{IOWR}\$ going to BDIR and \$\overline{IORD}\$ to BC1, both inverted, with \$\overline{Y1}\$ from the 138 going through an inverter to BC2.  I'll pull A8 high by connecting it to Vcc through a 1K resistor (is the resistor is necessary?)

I like your solution of using A₀ and A₁ to control BC1 and BC2, though for my setup I'd use A₀ to control BDIR and A₁ for BC1 as per my logic table earlier, with \$\overline{Y1}\$ controlling BC2 through an inverter.

So, with that setup, the following should be true?

* An OUT 09H should WRITE to the PSG
* An IN 0AH should READ from the PSG
* An OUT 0BH should LATCH ADDRESS in the PSG

Now that I have had 5 minutes to think about this, the following should work:



With A8 and BC2 pulled high and assuming \$\overline{SELAY}\$ is a suitable active-low decoded I/O select line.

When \$\overline{SELAY}\$ is inactive (high) then BC1 and BDIR will be low, when the select is active BDIR will be WR as required. The fact that A0 is inverted does not matter - it just changes the address map so that it becomes:

Base+0x00 (write) - latch address
Base+0x01 (r/w) - read/write to PSG

Which is IMO actually more logical.

EDIT: the above is slightly wrong - see later posts.

Have you thought about timings - your 8MHz Z80 is going to have \$\overline{WR}\$ active for a little over 250ns, for example, whereas the AY-3-8912 wants a minimum write pulse of 500ns.

[nockieboy]

Base+0x00 (write) - latch address
Base+0x01 (r/w) - read/write to PSG

Which is IMO actually more logical.

I agree - but my way means one less logic chip and space is at a premium.   In any case, at the moment it's likely circumstantial as your next comment leaves me some concern:

Have you thought about timings - your 8MHz Z80 is going to have \$\overline{WR}\$ active for a little over 250ns, for example, whereas the AY-3-8912 wants a minimum write pulse of 500ns.

No, I hadn't considered timings at all.   I suppose getting a theoretically-working design was the first hurdle.  I've even got it set out on breadboard and connected up to the SBC and have started on the assembly to get it making noise...  Which presumably it won't be doing as the timings are going to be an issue..

Okay, I'm off to start researching what I can do to sort this new problem out.  Some sort of latch, perhaps, to hold the \$\overline{WR}\$ low for the requisite time?  Remember though that I'm using \$\overline{Y1}\$ from the 138, A₀ and A₁ (for the time being.)

EDIT:

Something like this, perhaps to extend the pulse by RxC (or some proportional factor of RxC)?



Or better still, something involving a 74HCT123 retriggerable monostable multivibrator?

Is this the only timing problem that I'm likely to come across, though?  I'm going to have to extend the pulses both address lines and Y1?  Will the data bus be okay?

[grumpydoc]

I agree - but my way means one less logic chip and space is at a premium.   In any case, at the moment it's likely circumstantial as your next comment leaves me some concern:

Fair enough.

No, I hadn't considered timings at all.   I suppose getting a theoretically-working design was the first hurdle.  I've even got it set out on breadboard and connected up to the SBC and have started on the assembly to get it making noise...  Which presumably it won't be doing as the timings are going to be an issue..

Okay, I'm off to start researching what I can do to sort this new problem out.  Some sort of latch, perhaps, to hold the \$\overline{WR}\$ low for the requisite time?  Remember though that I'm using \$\overline{Y1}\$ from the 138, A₀ and A₁ (for the time being.)

EDIT:

Something like this, perhaps to extend the pulse by RxC (or some proportional factor of RxC)?



Or better still, something involving a 74HCT123 retriggerable monostable multivibrator?

Is this the only timing problem that I'm likely to come across, though?  I'm going to have to extend the pulses both address lines and Y1?  Will the data bus be okay?

No, you need to generate wait states.

You could build it and try out with a Z80 clock speed of 4MHz - if that works you can go back to 8MHz and see what happens.

[nockieboy]

No, you need to generate wait states.

You could build it and try out with a Z80 clock speed of 4MHz - if that works you can go back to 8MHz and see what happens.

Wait states? Something new to learn about there!

Okay, so you're suggesting before I get too wrapped up in timings I should confirm it all works at 4MHz then try it at 8 as there's a chance it could still work and either way would save me a lot of hassle by not jumping the gun? I really need to change my methodology as I'm in too much of a rush to get it working all the time!

The only consideration I can think of is that the serial comms speed will need to be halved if I do that, otherwise it should be pretty straightforward, I'm hoping?

Will let you know how it goes!